Hallo! Heute lernen wir ein Thema kennen, das sehr interessant und vor allem auf dem Arbeitsmarkt sehr gefragt ist: REST. Wir werden unseren Überblick über REST in drei Teile unterteilen:
Im ersten Teil befassen wir uns mit der Geschichte von REST und beschreiben die Prinzipien, auf denen REST basiert.
Im zweiten Schritt betrachten wir, wie die Kommunikation zwischen einem Client und einem Server über das HTTP-Protokoll erfolgt.
Im dritten Schritt schreiben wir eine kleine RESTful-Anwendung, die wir mit einem Programm namens „Postman“ testen.
Der Artikel richtet sich an Leser, die mit den folgenden Begriffen vertraut sind:
HTTP
URL und URI
JSON und (in geringerem Umfang) XML
Abhängigkeitsspritze
Teil 1. Was ist REST?
REST ist, wie so vieles in der IT-Welt, ein Akronym. Es leitet sich von „REpresentational State Transfer“ ab . Dies ist ein Architekturstil für die Interaktion zwischen Komponenten eines verteilten Systems in einem Computernetzwerk. Einfach ausgedrückt bestimmt REST den Stil der Interaktion (Datenaustausch) zwischen verschiedenen Komponenten des Systems, die sich jeweils physisch an verschiedenen Orten befinden können. Bei diesem Architekturstil handelt es sich um einen konsistenten Satz von Einschränkungen, die beim Entwurf eines verteilten Systems eingehalten werden. Diese Einschränkungen werden manchmal als die Leitprinzipien von REST bezeichnet. Es gibt nicht viele, nur 6. Wir werden etwas später darüber sprechen.
Anwendungen, die unter Berücksichtigung der REST-Prinzipien erstellt wurden, also solche, die die REST-Einschränkungen nicht verletzen, werden als „RESTful“ bezeichnet.
Geschichte von REST
Der Begriff REST wurde von Roy Fielding, einem der Erfinder des HTTP-Protokolls, in seiner Doktorarbeit eingeführt. Im Jahr 2000 promovierte er mit seiner Diplomarbeit mit dem Titel „Architectural Styles and the Design of Network-based Software Architectures“. Obwohl der Begriff REST noch als jung bezeichnet werden kann, liegt das Konzept, das er repräsentiert, im Kern des World Wide Web. Wir werden nicht tief in die Geschichte des Begriffs eintauchen. Wenn Sie in die Primärquellen 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 einen Anfrage-Antwort-Prozess. Die Komponente, die die Anfrage sendet, wird als Client bezeichnet , und 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 das HTTP-Protokoll gesendet. HTTP steht für HyperText Transfer Protocol. Typischerweise handelt es sich bei einem Server um eine Webanwendung. Der Kunde kann fast alles sein. Zum Beispiel eine mobile App, die Daten von einem 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. In diesem Fall ist A ein Client in Bezug auf B und B ein Server in Bezug auf A. Gleichzeitig könnte A Anforderungen von B, C, D usw. verarbeiten. In diesem Fall ist Anwendung A sowohl Server als auch Client. Alles hängt vom Kontext ab. Eines ist sicher: Die Komponente, die die Anfrage sendet, ist der Client. Die Komponente, die eine Anfrage empfängt, verarbeitet und beantwortet, ist der Server. Jedoch, Nicht jedes System, dessen Komponenten über einen Anfrage-Antwort-Prozess kommunizieren, ist ein RESTful-System. Damit ein System als RESTful gilt, muss es die sechs REST-Einschränkungen erfüllen:
1. Client-Server-Architektur
Bei dieser Einschränkung geht es um die Trennung von Belangen. Es ist notwendig, die Anforderungen der Client-Schnittstelle von den Anforderungen des Servers, der die Daten speichert, zu trennen. Diese Einschränkung macht den Client-Code besser auf andere Plattformen übertragbar und die Vereinfachung der Serverseite verbessert die Skalierbarkeit des Systems. Durch die Unterscheidung zwischen „Client“ und „Server“ können diese unabhängig voneinander entwickelt werden.
2. Staatenlos
Für eine RESTful-Architektur müssen die folgenden Bedingungen erfüllt sein. Im Zeitraum zwischen den Anfragen darf der Server keine Informationen über den Status des Clients speichern und umgekehrt. Alle Anfragen des Clients müssen so zusammengestellt sein, dass der Server alle notwendigen Informationen erhält, um die Anfrage abzuschließen. Somit können sowohl der Server als auch der Client jede empfangene Nachricht „verstehen“, ohne sich auf vorherige Nachrichten verlassen zu müssen.
3. Cachebar
Clients können Serverantworten zwischenspeichern. Diese wiederum müssen explizit oder implizit als zwischengespeichert oder nicht zwischengespeichert gekennzeichnet werden, damit Clients bei nachfolgenden Anfragen keine veralteten oder falschen Daten erhalten. Korrektes Caching trägt dazu bei, einige Client-Server-Interaktionen ganz oder teilweise zu eliminieren und so die Systemleistung und Skalierbarkeit weiter zu steigern.
4. Einheitliche Schnittstelle
Zu den grundlegenden Anforderungen einer RESTful-Architektur gehört eine einheitliche Schnittstelle. Der Client muss immer das Format und die Adressen verstehen, die er beim Senden einer Anfrage verwenden muss, und der Server wiederum muss auch das Format verstehen, das er verwenden sollte, wenn er auf Clientanfragen antwortet. Diese konsistente Client-Server-Interaktion, die beschreibt, was, wo, in welcher Form und wie Daten gesendet werden sollen, ist eine einheitliche Schnittstelle.
5. Schichten
Mit Schichten meinen wir die hierarchische Struktur des Netzwerks. Manchmal kann ein Client direkt mit dem Server kommunizieren, manchmal kommuniziert er nur mit einem Zwischenknoten. Der Einsatz von Zwischenservern kann dank Lastausgleich und verteiltem Caching die Skalierbarkeit erhöhen. Lassen Sie uns ein Beispiel geben. Stellen Sie sich eine mobile App vor, die auf der ganzen Welt beliebt ist. Ein wesentlicher Bestandteil der App ist das Laden von Bildern. Die Zahl seiner Nutzer geht in die Millionen, sodass ein einzelner Server eine so hohe Auslastung nicht bewältigen kann. Durch die Aufteilung des Systems in Schichten wird dieses Problem gelöst. Wenn der Client ein Bild von einem Zwischenknoten anfordert, dann fordert der Zwischenknoten das Bild von dem Server an, der gerade am wenigsten geladen ist, und sendet das Bild an den Client zurück. Wenn das Caching auf jeder Ebene der Hierarchie korrekt angewendet wird,
6. Code auf Anfrage (optional)
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.
Vorteile einer RESTful-Architektur
Anwendungen, die alle oben genannten Einschränkungen erfüllen, haben die folgenden Vorteile: Zuverlässigkeit (keine Notwendigkeit, den Status des Clients zu speichern, der verloren gehen könnte)
Leistung (aufgrund der Verwendung eines Caches)
Skalierbarkeit
transparente Kommunikation
einfache Schnittstellen
Portabilität
Fähigkeit, Änderungen einfach vorzunehmen
Fähigkeit zur Weiterentwicklung und Anpassung an neue Anforderungen
Wir werden unseren Überblick über REST in drei Teile unterteilen:
GO TO FULL VERSION