Hallo, heute werden wir uns mit einem sehr interessanten und vor allem gefragten Thema auf dem Arbeitsmarkt befassen – REST. Wir werden den Überblick über REST in drei Teile unterteilen:
Im ersten Teil werden wir auf die Geschichte von REST eingehen und die Prinzipien beschreiben, auf denen REST basiert.
Im zweiten schauen wir uns an, wie die Kommunikation zwischen Client und Server über das HTTP-Protokoll erfolgt.
Im dritten Schritt schreiben wir eine kleine RESTful-Anwendung, die wir mit dem Postman-Programm testen.
Der Artikel richtet sich an Leser, die mit den folgenden Begriffen vertraut sind:
HTTP;
URL und URI;
JSON und in geringerem Maße XML;
Abhängigkeitsspritze.
Teil 1. Was ist REST?
REST ist, wie viele Dinge in der IT-Welt, ein Akronym für Representational State Transfer . Dies ist ein architektonischer Stil der Interaktion zwischen verteilten Systemkomponenten in einem Computernetzwerk. Einfach ausgedrückt definiert REST einen Interaktionsstil (Datenaustausch) zwischen verschiedenen Komponenten eines Systems, die sich jeweils physisch an unterschiedlichen Orten befinden können. Dieser Architekturstil stellt einen konsistenten Satz von Einschränkungen dar, die beim Entwurf eines verteilten Systems berücksichtigt werden. Diese Einschränkungen werden manchmal als REST-Prinzipien bezeichnet. Es gibt nicht viele davon, nur 6 Stück. Wir werden etwas später darüber sprechen.
Anwendungen, die unter Berücksichtigung von REST erstellt wurden, d. h. die die von REST auferlegten Einschränkungen nicht verletzen, werden als RESTful bezeichnet.
Geschichte von REST
Der Begriff REST wurde im Jahr 2000 von Roy Fielding, einem der Erfinder des HTTP-Protokolls, in seiner Doktorarbeit „Architectural Styles and the Design of Network-based Software Architectures“ geprägt. Wir können sagen, dass der Begriff REST noch jung ist, obwohl sein Konzept die Grundlage des World Wide Web bildet. Wir werden nicht tief in die Entstehungsgeschichte dieses Begriffs eintauchen. Wenn Sie in die Originalquellen eintauchen möchten, werfen Sie einen Blick auf Fieldings Dissertation .
REST-Einschränkungen und -Prinzipien
Wie oben erwähnt, definiert REST, wie die Komponenten eines verteilten Systems miteinander interagieren sollen. Im Allgemeinen geschieht dies durch Request-Response. Die Komponente, die die Anfrage sendet, wird als Client bezeichnet . Die Komponente, die die Anfrage verarbeitet und eine Antwort an den Client sendet, wird als Server bezeichnet . Anfragen und Antworten werden am häufigsten über HTTP (HyperText Transfer Protocol) gesendet. Normalerweise ist ein Server eine Art Webanwendung. Der Kunde kann nicht irgendetwas sein, sondern ziemlich viel. Zum Beispiel eine mobile Anwendung, die Daten vom Server anfordert. Oder ein Browser, der Anfragen von einer Webseite an einen Server sendet, um Daten herunterzuladen. Anwendung A kann Daten von Anwendung B anfordern. Dann ist A ein Client im Verhältnis zu B und B ein Server im Verhältnis zu A. Gleichzeitig kann A Anfragen von C, D, D usw. verarbeiten. In diesem Fall ist Anwendung A sowohl Server als auch Client. Es hängt alles vom Kontext ab. Eines ist klar: Die Komponente, die die Anfrage sendet, ist der Client. Die Komponente, die die Anfrage empfängt, verarbeitet und beantwortet, ist der Server. Allerdings ist nicht jedes System, dessen Komponenten über Request-Response kommunizieren, ein REST-System (oder RESTful-System). Damit ein System als REST-konform gilt, muss es sechs REST-Einschränkungen „erfüllen“:
1. Überführung der Architektur in ein Client-Server-Modell
Grundlage dieser Einschränkung ist die Differenzierung der Bedürfnisse. Es ist notwendig, die Anforderungen der Client-Schnittstelle von den Anforderungen des Servers, der die Daten speichert, zu trennen. Diese Einschränkung erhöht die Portabilität des Client-Codes auf andere Plattformen und die Vereinfachung des Serverteils verbessert die Skalierbarkeit des Systems. Die Unterscheidung zwischen „Client“ und „Server“ ermöglicht es ihnen, sich unabhängig voneinander zu entwickeln.
2. Mangelnde Kondition
Für die REST-Architektur muss die folgende Bedingung erfüllt sein. Zwischen Anfragen muss der Server keine Informationen über den Status des Clients speichern und umgekehrt. Alle Anfragen des Clients müssen so strukturiert sein, dass der Server alle notwendigen Informationen erhält, um die Anfrage abzuschließen. Auf diese Weise können sowohl der Server als auch der Client jede empfangene Nachricht „verstehen“, ohne sich auf vorherige Nachrichten verlassen zu müssen.
3. Caching
Clients können Serverantworten zwischenspeichern. Diese wiederum müssen explizit oder implizit als zwischenspeicherbar oder nicht zwischenspeicherbar gekennzeichnet sein, damit Clients bei nachfolgenden Anfragen keine veralteten oder falschen Daten erhalten. Der richtige Einsatz von Caching trägt dazu bei, einige Client-Server-Interaktionen ganz oder teilweise zu eliminieren und so die Systemleistung und Erweiterbarkeit weiter zu steigern.
4. Einheitlichkeit der Schnittstelle
Zu den grundlegenden Anforderungen der REST-Architektur gehört eine einheitliche, konsistente Schnittstelle. Der Client muss immer verstehen, in welchem Format und an welche Adressen er eine Anfrage senden muss, und der Server wiederum muss auch verstehen, in welchem Format er auf Client-Anfragen antworten soll. Dabei handelt es sich um ein einheitliches Format für die Client-Server-Interaktion, das beschreibt, was, wohin, in welcher Form und wie gesendet werden soll und eine einheitliche Schnittstelle darstellt
5. Schichten
Schichten beziehen sich auf die hierarchische Struktur von Netzwerken. Manchmal kann der Client direkt mit dem Server kommunizieren, manchmal kann er einfach mit einem Zwischenknoten kommunizieren. Der Einsatz von Zwischenservern kann die Skalierbarkeit durch Lastausgleich und verteiltes Caching erhöhen. Geben wir ein Beispiel. Stellen wir uns eine mobile Anwendung vor, die auf der ganzen Welt beliebt ist. Sein wesentlicher Bestandteil ist das Laden von Bildern. Da es Millionen von Benutzern gibt, könnte ein Server einer so hohen Belastung nicht standhalten. Durch die Aufteilung des Systems in Schichten wird dieses Problem gelöst. Der Client fordert ein Bild vom Zwischenknoten an, der Zwischenknoten fordert das Bild vom Server an, der gerade am wenigsten belastet ist, und gibt das Bild an den Client zurück. Wenn Caching hier auf jeder Ebene der Hierarchie korrekt angewendet wird, kann eine gute Systemskalierbarkeit erreicht werden.
6. Code auf Anfrage (optionale Einschränkung)
Diese Einschränkung impliziert, dass der Client seine Funktionalität erweitern kann, indem er Code vom Server in Form von Applets oder Skripten herunterlädt.
Die Vorteile von REST
Anwendungen, die alle oben genannten Einschränkungen erfüllen, bieten die folgenden Vorteile: Zuverlässigkeit (keine Notwendigkeit, Client-Statusinformationen zu speichern, die verloren gehen könnten);
Leistung (aufgrund der Verwendung von Cache);
Skalierbarkeit;
Transparenz des Interaktionssystems;
Einfachheit der Schnittstellen;
Portabilität von Komponenten;
einfache Durchführung von Änderungen;
die Fähigkeit, sich weiterzuentwickeln und sich an neue Anforderungen anzupassen.
GO TO FULL VERSION