Representational State Transfer (REST)

Was ist Representational State Transfer (REST)

REST (Representational State Transfer) ist ein Architekturstil für die Entwicklung von Webdiensten und Systemen, die einfach miteinander kommunizieren können. REST ist beliebt aufgrund seiner Einfachheit und der Tatsache, dass es auf bestehenden Systemen und Funktionen des HTTP-Internets aufbaut, um seine Ziele zu erreichen, anstatt neue Standards, Frameworks und Technologien zu schaffen.

Es wird allgemein angenommen, dass REST ein Protokoll oder ein Standard ist. Es ist jedoch weder das eine noch das andere. REST ist ein architektonischer Stil, der üblicherweise für die Erstellung webbasierter Programmierschnittstellen (APIs) verwendet wird.

Bei diesem Architekturstil interagieren die Systeme durch Operationen mit Ressourcen. Zu den Ressourcen gehören alle Daten und Funktionen. Der Zugriff auf sie erfolgt über Uniform Resource Identifiers (URIs) und die Ausführung von einfachen Operationen.

Systeme, Dienstschnittstellen oder APIs, die dem REST-Architekturstil entsprechen, werden als RESTful-Systeme (oder RESTful APIs) bezeichnet. In der Regel sind diese Anwendungen leichtgewichtig, schnell, zuverlässig, skalierbar und portabel.

REST-Bedingungen

Damit ein System RESTful sein kann, muss es fünf obligatorische Bedingungen erfüllen:

• Es muss über eine einheitliche Schnittstelle verfügen, um die Systemarchitektur zu vereinfachen und die Sichtbarkeit der Interaktionen zwischen den Systemkomponenten zu verbessern.
• Es muss das Client-Server-Designmuster einbeziehen, das die Trennung von Belangen und eine unabhängige Implementierung von Client und Server ermöglicht.
• Es muss zustandslos sein, das heißt Server und Client müssen nichts über den Zustand des jeweils anderen wissen, so dass beide die vom jeweils anderen empfangenen Nachrichten verstehen können, ohne frühere Nachrichten sehen zu müssen.
• Es muss cachefähig sein, das heißt eine Antwort sollte sich selbst als cachefähig oder nicht cachefähig kennzeichnen, und Kopien von Daten, auf die häufig zugegriffen wird, müssen in mehreren Caches entlang des Anfrage-Antwort-Pfads gespeichert werden.
• Es muss mehrschichtig sein, um das Verhalten der Komponenten einzuschränken, die Notwendigkeit der Codebearbeitung (auf dem Client oder Server) zu beseitigen und die Sicherheit der Webanwendung zu verbessern.

Darüber hinaus kann das Client-System seine Funktionalität mit Hilfe von Code-Applets oder Skripten erweitern. Diese Einschränkung bei REST wird allgemein als Code on demand bezeichnet.

REST und die HTTP-Methoden

In einem REST-System werden zahlreiche Ressourcenmethoden für Ressourceninteraktionen und zur Ermöglichung von Ressourcenzustandsübergängen verwendet. Diese Methoden werden auch als HTTP-Verben bezeichnet.

Die Standardoperation von HTTP ist GET, die verwendet wird, wenn eine Ressource oder ein Ressourcensatz vom Server durch Angabe der Ressourcen-ID abgerufen wird. Neben GET definiert HTTP auch mehrere andere Anforderungsmethoden, darunter PUT (Aktualisierung einer Ressource nach ID), POST (Erstellen einer neuen Ressource) und DELETE (Entfernen einer Ressource nach ID).

Die REST-Philosophie besagt, dass man zum Löschen einer Ressource auf dem Server einfach die URL für die Ressource verwenden und die DELETE-Methode von HTTP angeben muss. Um Daten auf dem Server zu speichern, wird eine URL und die PUT-Methode verwendet. Für Vorgänge, die über das einfache Speichern, Lesen oder Löschen von Informationen hinausgehen, kann die POST-Methode von HTTP verwendet werden.

Vorteile von REST

Die Verwendung der REST-Architektur für Webanwendungen bietet die folgenden Vorteile:

• Ressourcenbasiert. REST erzwingt Zustandslosigkeit durch Ressourcen anstelle von Befehlen, was die Zuverlässigkeit, Leistung und Skalierbarkeit verbessert.
• Einfache Schnittstelle. Bei REST wird jede an Client-Server-Interaktionen beteiligte Ressource identifiziert und in der Serverantwort einheitlich dargestellt, um eine konsistente und einfache Schnittstelle für alle Interaktionen zu definieren.
• Vertraute Konstrukte. REST-Interaktionen basieren auf Konstrukten, die jedem vertraut sind, der mit HTTP arbeitet, einschließlich Operationen (GET, POST, DELETE usw.) und URIs. Dennoch sind REST und HTTP nicht dasselbe und Entwickler müssen die Unterschiede bei der Implementierung und Verwendung von REST beachten.
• Kommunikation. Der Status von REST-basierten Interaktionen zwischen dem Server und den Clients wird durch numerische HTTP-Statuscodes mitgeteilt. REST APIs verwenden die folgenden HTTP-Statuscodes, um Fehler zu erkennen und den API-Überwachungsprozess zu erleichtern:
  • Der 400-Fehler zeigt an, dass die Anfrage aufgrund einer fehlerhaften Anfrage nicht verarbeitet werden kann.
  • Der 404-Fehler zeigt an, dass eine angeforderte Ressource nicht gefunden wurde.
  • Der 401-Status-Antwort-Code wird durch eine nicht autorisierte Anfrage ausgelöst.
  • Der 200-Status-Antwort-Code zeigt an, dass eine Anfrage erfolgreich war.
  • Der 500-Fehler signalisiert einen unerwarteten internen Serverfehler.

Die gesamte Kommunikation zwischen Service-Agenten und Komponenten ist vollständig sichtbar, was die Zuverlässigkeit des Systems erhöht.

• Sprachunabhängig. Bei der Erstellung von RESTful APIs oder Webdiensten können Entwickler jede Sprache verwenden, die HTTP nutzt.
• Weitverbreitete Nutzung. REST ist weit verbreitet und daher eine beliebte Wahl für zahlreiche server- und clientseitige Implementierungen. Auf der Serverseite können Entwickler beispielsweise REST-basierte Frameworks wie Restlet und Apache CXF verwenden, während sie auf der Clientseite jQuery, Node.js, Angular oder Ember.js einsetzen und RESTful-Webdienste mit Hilfe von Standardbibliotheken, die in ihre APIs integriert sind, aufrufen können.
• Web-APIs. RESTful-Dienste nutzen effektive HTTP-Mechanismen für die Zwischenspeicherung, um die Latenz und die Serverlast zu verringern.
• Trennung von Client und Server. Durch die Bereitstellung zahlreicher Endpunkte erleichtert eine REST API die Erstellung komplexer Abfragen, die spezifische Einsatzanforderungen erfüllen können. Außerdem greifen verschiedene Clients auf dieselben REST-Endpunkte zu und erhalten dieselben Antworten, wenn sie eine REST-Schnittstelle verwenden, was die Zuverlässigkeit und Leistung verbessert.
• Ausfallsicherheit. In einem REST-System führt der Ausfall eines einzelnen Anschlusses oder einer Komponente nicht zum Zusammenbruch des gesamten Systems.

Nachteile von REST

Trotz ihrer Vorteile gibt es einige Nachteile der REST-Architektur, die Entwickler kennen sollten:

• Designeinschränkungen. Das Design der REST-Architektur weist einige Einschränkungen auf. Dazu gehören das Multiplexing mehrerer Anfragen über eine einzige TCP-Verbindung, unterschiedliche Ressourcenanfragen für jede Ressourcendatei, Uploads von Serveranfragen und lange HTTP-Anfrage-Header, die zu Verzögerungen beim Laden von Webseiten führen. Außerdem kann die Freiheit, die REST in Bezug auf Designentscheidungen bietet, dazu führen, dass REST APIs schwieriger zu verwalten sind.
• Zustandslose Anwendungen. Da der Server keine zustandsbasierten Informationen zwischen Anfrage-Antwort-Zyklen speichert, muss der Client Aufgaben der Zustandsverwaltung durchführen, was die Implementierung von Serveraktualisierungen ohne clientseitiges Polling oder andere Arten von Webhooks, die Daten und ausführbare Befehle zwischen Anwendungen senden, erschwert.
• Definition. Für REST gibt es keine klare Referenzimplementierung oder einen definitiven Standard, um zu bestimmen, ob ein Entwurf als RESTful definiert werden kann oder ob eine Web-API den REST-basierten Grundsätzen entspricht.
• Übermäßiges Abrufen/Unterabrufen von Daten. RESTful-Dienste geben häufig große Mengen unbrauchbarer Daten zusammen mit relevanten Informationen zurück – in der Regel das Ergebnis mehrerer Serverabfragen –, wodurch sich die Zeit verlängert, die ein Client benötigt, um alle erforderlichen Daten zurückzugeben.

REST-Entwicklung: URIs und URLs

Mit dem RESTful-Ansatz für die Entwicklung von Anwendungen ist die Abfrage von Informationen über den Zustand einer Ressource so einfach wie das Aufrufen ihrer URL.

Wenn ein Client beispielsweise einen Webdienst aufrufen möchte, der alle bei TechTarget verfügbaren Quiz auflistet, würde die URL des Webdienstes etwa wie folgt aussehen:

www.techtarget.com/restfulapi/quizzes

Nach dem Aufruf könnte der Webservice mit dem folgenden JSON-String antworten, in der alle verfügbaren Quiz aufgelistet sind, von denen sich eines mit DevOps beschäftigt:

{ "quizzes" : [ "Java", "DevOps", "IoT"] }

Um das DevOps-Quiz abzurufen, könnte der Webdienst über die folgende URL aufgerufen werden:

www.techtarget.com/restfulapi/quizzes/DevOps

Der Aufruf dieser URL würde einen JSON-String zurückgeben, in dem alle Fragen des DevOps-Quiz aufgelistet sind. Um eine einzelne Frage aus dem Quiz abzurufen, würde die Nummer der Frage zur URL hinzugefügt werden.

Um also die dritte Frage im DevOps-Quiz abzurufen, würde die folgende RESTful-URL verwendet werden:

www.techtarget.com/restfulapi/quizzes/DevOps/3

Das Aufrufen dieser URL könnte eine JSON-Zeichenfolge wie die folgende zurückgeben:

{ "Question" : {"query": "Was ist Ihre DevOps-Rolle?", "optionA": "Dev", "optionB": "Ops"} }

Im obigen Beispiel sind die REST URLs logisch und sinnvoll strukturiert, so dass die angeforderte Ressource genau identifiziert werden kann.

JSON- und XML-REST-Datenformate

Bei REST sind die beiden gängigsten Datenaustauschformate JSON und XML. Viele RESTful-Webdienste können beide Formate austauschbar verwenden, solange der Client die Interaktion in einem der beiden Formate anfordern kann.

Man sollte beachten, dass JSON und XML zwar gängige Formate für den Datenaustausch sind, REST selbst aber keine Einschränkungen hinsichtlich des Formats macht. Tatsächlich tauschen einige RESTful-Webdienste aus Gründen der Effizienz binäre Daten aus. Dies ist ein weiterer Vorteil der Arbeit mit REST-basierten Webdiensten, da Softwarearchitekten viel Freiheit bei der Entscheidung haben, wie ein RESTful-Dienst am besten zu implementieren ist.

Entwicklung von REST-APIs in Java

Um der wachsenden Beliebtheit von REST-basierten Systemen Rechnung zu tragen, gibt es mehrere Frameworks, die Entwicklern bei der Erstellung von RESTful-Webdiensten helfen. Zu den beliebtesten Open-Source-Frameworks für die Erstellung von Java-basierten RESTful-Webdiensten gehören Apache CXF, Jersey, Restlet, Spring Data und JBoss RESTEasy.

Der allgemeine Ansatz dieser Frameworks besteht darin, Entwicklern bei der Erstellung von RESTful-Webdiensten zu helfen, indem sie eine Semantik verwenden, die Java-Entwicklern vertraut ist, einschließlich der Java Platform, Enterprise Edition (J2EE) Servlet-API und Annotationen, und gleichzeitig integrierte Klassen und Methoden anbieten, die es einfacher machen, die grundlegenden Prinzipien von REST einzuhalten.

Alternativen zu REST

REST erleichtert die Implementierung von netzwerkbasierten Webdiensten, indem es das Grundkonstrukt des Netzwerkprotokolls selbst verwendet, das im Falle des Internets HTTP heißt. Die Entwickler müssen also nicht mit benutzerdefinierten Protokollen für den Nachrichtenaustausch zwischen Client und Server arbeiten. Das ist wichtig, da REST und seine Grundsätze nicht nur für das Internet, sondern für alle Protokolle, einschließlich WebDAV und FTP, gelten sollen.

Abgesehen davon eignet sich REST hauptsächlich für CRUD-Anwendungen (Create, Read, Update, Delete), bei denen die fünf HTTP-Methoden (GET, PUT, POST, PATCH, DELETE) problemlos verwendet werden können. Für andere Arten von Anwendungen oder Anwendungsfällen ist REST möglicherweise nicht die beste Wahl. Beispiele hierfür sind Anwendungen, die dauerhafte zustandsbehaftete Verbindungen erfordern, Anwendungen, die auf komplexe verknüpfte Daten angewiesen sind (oder diese abrufen), Anwendungen für Benachrichtigungen oder Anwendungen wie Live-Chats oder kollaborative Arbeitsbereiche.

Für diese und andere Anwendungen sind die folgenden Alternativen möglicherweise besser geeignet als REST:

• GraphQL
• gRPC
• MQTT
• WebSocket

Für die Entwicklung von SOA-basierten Systemen oder die Erstellung von APIs für den Aufruf von Remote-Microservices sind Technologien wie XML über HTTP (XML-RPC), CORBA, RMI über IIOP und das Simple Object Access Protocol (SOAP) möglicherweise die bessere Wahl als REST.

REST versus SOAP

REST und SOAP werden beide für die Implementierung von Webdiensten verwendet. Der grundlegende Unterschied zwischen ihnen liegt in ihrem Ansatz für Remote-Aufrufe. REST verfolgt einen ressourcenbasierten Ansatz für webbasierte Interaktionen. Bei REST suchen Sie eine Ressource auf dem Server und entscheiden, ob Sie diese Ressource aktualisieren, löschen oder Informationen über sie abrufen wollen. Bei SOAP interagiert der Client nicht direkt mit einer Ressource, sondern ruft stattdessen einen Dienst auf, der dann den Zugriff auf die verschiedenen Objekte und Ressourcen vermittelt.

SOAP hat auch viele Frameworks und APIs auf HTTP aufgebaut, darunter die Web Services Description Language (WSDL), die die Struktur der Daten definiert, die zwischen dem Client und dem Server hin- und hergeschickt werden.

Für einige Problembereiche ist es sinnvoll, das Nachrichtenformat genau zu definieren, oder sie profitieren von der Verwendung verschiedener SOAP-bezogener APIs, wie WS-Eventing, WS-Notification und WS-Security. In manchen Situationen kann HTTP nicht den Grad an Funktionalität bieten, den eine Anwendung benötigt, so dass die Verwendung von SOAP vorzuziehen ist.

REST und IoT

In einer Internet-der-Dinge-Umgebung (Internet of Things, IoT) arbeiten Geräte in einer Client-Server-Beziehung und können als Client, Server oder beides fungieren. Als Client kann ein IoT-Gerät den Kontakt mit einem Verzeichnis, zum Beispiel dem CoRE-Ressourcenverzeichnis, oder einem anderen Gerät herstellen, während es als Ursprungsserver oder -ressource als Temperatur- oder andere Art von Sensor dienen kann.

Die nahezu allgegenwärtige Verbreitung von REST APIs und die wachsende Zahl von Geräten im Internet der Dinge machen REST zu einer geeigneten Architektur hierfür. Außerdem sind die Daten, die von Ressourcen im IoT angefordert werden, in der Regel einfach (zum Beispiel der aktuelle Messwert eines Sensors) und statisch (zum Beispiel die Gerätebeschreibung eines Herstellers), was REST – das HTTP nutzt – zu einer natürlichen Lösung macht. Drittens werden im Internet der Dinge kompakte Formate auf der Grundlage von JSON, EXI und CBOR (Concise Binary Object Representation – ein Ableger von JSON) verwendet. RESTful APIs sind ebenfalls kompakt, was sie wiederum für IoT-Anwendungen geeignet macht.

Geschichte von REST

REST wurde erstmals vom Informatiker Roy Thomas Fielding im Jahr 2000 im Rahmen seiner Dissertation an der University of California, Irvine, mit dem Titel Architectural Styles and the Design of Network-based Software Architectures entwickelt.

In Kapitel 5 der Dissertation, Representational State Transfer (REST), wurde REST als Architekturstil für verteilte Hypermedia-Systeme beschrieben. In diesem Kapitel stellte Fielding die fünf zuvor beschriebenen Bedingungen fest, die definieren, wie sich RESTful-Systeme verhalten sollten.