Representational State Transfer (REST)

Vor- und Nachteile von REST

Die Verwendung von REST hat mehrere Vorteile:

• Ressourcen. Ein Hauptvorteil der Verwendung von REST, sowohl aus der Sicht des Clients als auch des Servers, besteht darin, dass die REST-Interaktionen auf Strukturen basieren, die jedem vertraut sind, der mit HTTP vertraut ist. Durch die Verwendung eines ressourcenbasierten Ansatzes definiert REST, wie Entwickler mit Webdiensten interagieren.
• Kommunikation. REST-basierte Interaktionen teilen ihren Status durch numerische HTTP-Statuscodes mit. REST APIs verwenden diese HTTP-Statuscodes, um Fehler zu erkennen und den API-Überwachungsprozess zu erleichtern. Dazu gehören:
  • Der Fehler 404 zeigt an, dass eine angeforderte Ressource nicht gefunden wurde.
  • Der 401-Status-Antwortcode wird durch eine nicht autorisierte Anfrage ausgelöst.
  • Der 200-Status-Antwortcode zeigt an, dass eine Anfrage erfolgreich war.
  • Der 500-Fehler signalisiert einen nicht behebbaren Anwendungsfehler auf dem Server.
• Bekanntheit. Die meisten Entwickler sind bereits mit den Schlüsselelementen der REST-Architektur vertraut, wie zum Beispiel SSL-Verschlüsselung (Secure Sockets Layer) und Transport Layer Security (TLS).
• Sprachunabhängig. Bei der Erstellung von RESTful APIs oder Webdiensten können Entwickler jede Sprache verwenden, die HTTP für webbasierte Anfragen nutzt. Diese Fähigkeit macht es Programmierern leicht, die Technologien zu wählen, mit denen sie am liebsten arbeiten und die ihren Anforderungen am besten entsprechen.
• Verbreitung. Die Popularität von REST ist auf seine weit verbreitete Verwendung sowohl in server- als auch in clientseitigen Implementierungen zurückzuführen. Auf der Serverseite können Entwickler zum Beispiel REST-basierte Frameworks wie Restlet und Apache CXF einsetzen. Auf der Client-Seite können Entwickler eine Vielzahl von Frameworks einsetzen (zum Beispiel jQuery, Node.js, Angular und EmberJS) und RESTful-Webdienste mit Standardbibliotheken aufrufen, die in ihre APIs integriert sind.
• Web-APIs. Für die Zwischenspeicherung nutzen RESTful-Dienste effektive HTTP-Mechanismen. Durch die Bereitstellung zahlreicher Endpunkte erleichtert eine REST API Entwicklern beispielsweise die Erstellung komplexer Abfragen, die spezifische Einsatzanforderungen erfüllen können.

Die Nachteile von REST sind:

• Architektur. Entwickler, die mit REST arbeiten, stoßen häufig auf Einschränkungen aufgrund der Architektur. 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.
• Zustandslose Anwendungen. Da HTTP keine zustandsbasierten Informationen zwischen Anfrage-Antwort-Zyklen speichert, muss der Client Aufgaben der Zustandsverwaltung durchführen. Dies macht es für Programmierer schwierig, Serveraktualisierungen ohne clientseitiges Polling oder andere Arten von Webhooks zu implementieren, die Daten und ausführbare Befehle von einer Anwendung zur anderen senden.
• Definition. Entwickler sind sich im Allgemeinen uneinig über die Definition von REST-Designs. Für den Architekturstil REST gibt es keine klare Referenzimplementierung oder einen definitiven Standard, der festlegt, ob ein bestimmtes Design als RESTful definiert werden kann. Dies führt auch zu Unsicherheit darüber, ob eine bestimmte Web-API den REST-basierten Prinzipien entspricht.
• Übermäßiges Abrufen von Daten. RESTful-Dienste liefern häufig große Mengen an unbrauchbaren Daten in Kombination mit relevanten Informationen, die in der Regel das Ergebnis mehrerer Serverabfragen sind. Diese Ineffizienzen erhöhen auch die Zeit, die ein Client benötigt, um alle erforderlichen Daten zurückzugeben.

Alternativen zu REST

Zu den alternativen Technologien für die Entwicklung von SOA-Systemen oder die Erstellung von APIs für den Aufruf entfernter Microservices gehören XML over HTTP (XML-RPC), CORBA, RMI over IIOP und das Simple Object Access Protocol (SOAP).

Im Allgemeinen hat jede Technologie Vor- und Nachteile. Ein einzigartiges Merkmal von REST besteht jedoch darin, dass Entwickler nicht mit benutzerdefinierten Protokollen für den Client-Server-Nachrichtenaustausch arbeiten müssen. REST kann das grundlegende Konstrukt des Netzwerkprotokolls selbst verwenden, was im Hinblick auf das Internet HTTP ist.

Dies ist eine wichtige Komponente, da REST nicht nur für das Internet gedacht ist, sondern seine Prinzipien für alle Protokolle gelten sollen, einschließlich WebDav und FTP.

REST versus SOAP

Die beiden konkurrierenden Stile für die Implementierung von Webdiensten sind REST und SOAP. Der grundlegende Unterschied zwischen beiden ist der Ansatz, den sie für Remote-Aufrufe verfolgen.

REST verfolgt einen ressourcenbasierten Ansatz für webbasierte Interaktionen. Bei REST suchen Sie eine Ressource auf dem Server, und Sie können diese Ressource entweder aktualisieren, löschen oder Informationen darüber abrufen.

Bei SOAP interagiert der Client nicht direkt mit einer Ressource, sondern ruft stattdessen einen Dienst auf, der im Hintergrund den Zugriff auf die verschiedenen Objekte und Ressourcen vermittelt.

SOAP hat auch eine große Anzahl von Frameworks und APIs auf HTTP aufgesetzt, darunter die Web Services Description Language (WSDL), die die Struktur der Daten definiert, die zwischen Client und Server hin- und hergeschickt werden.

Für einige Problembereiche ist es sinnvoll, das Nachrichtenformat genau zu definieren, oder sie können von der Verwendung verschiedener SOAP-bezogener APIs profitieren, wie WS-Eventing, WS-Notification und WS-Security. Es gibt Fälle, in denen HTTP nicht den Grad an Funktionalität bieten kann, den eine Anwendung benötigt, und in diesen Fällen ist die Verwendung von SOAP vorzuziehen.

REST-Entwicklung

REST URIs und URLs

Die meisten Programmierer sind mit der Art und Weise vertraut, wie URLs und URIs im Web funktionieren. Ein REST-Ansatz für die Entwicklung von Anwendungen geht davon aus, dass die Abfrage von Informationen über den Zustand einer Ressource so einfach sein sollte wie der Aufruf der entsprechenden URL.

Wenn ein Client beispielsweise einen Webservice aufrufen möchte, der alle bei TechTarget verfügbaren Quizze auflistet, würde die URL zum Webservice etwa so aussehen:

www.techtarget.com/restfulapi/quizzes

Nach dem Aufruf könnte der Webservice mit der folgenden JSON-Zeichenkette 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, kann 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:

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

Wie Sie sehen, sind die REST URLs in diesem Beispiel logisch und sinnvoll strukturiert, so dass die angeforderte Ressource genau identifiziert werden kann.

JSON- und XML-REST-Datenformate

Im obigen Beispiel wurde JSON als Datenaustauschformat für die RESTful-Interaktion verwendet. Die beiden gängigsten Datenaustauschformate sind JSON und XML, und viele RESTful-Webdienste können beide Formate austauschbar verwenden, solange der Client die Interaktion in einem der beiden Formate anfordern kann.

Beachten Sie, 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 der Softwarearchitekt einen großen Spielraum hat, wie er einen Dienst am besten implementiert.

REST und HTTP-Methoden

Im obigen Beispiel ging es nur um den Zugriff auf Daten.

Die Standardoperation von HTTP ist GET, die für den Abruf von Daten vom Server gedacht ist. HTTP definiert jedoch mehrere andere Methoden, darunter PUT, POST und DELETE.

Der REST-Ansatz besagt, dass man zum Löschen von Daten auf dem Server einfach die URL für die Ressource verwendet und die DELETE-Methode von HTTP angibt. 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.

Entwicklung von REST APIs in Java

Um der wachsenden Beliebtheit von REST-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, Apache Wink, Spring Data und RESTEasy von JBoss.

Der allgemeine Ansatz jedes 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), der Servlet-API und Annotationen, während sie gleichzeitig integrierte Klassen und Methoden anbieten, die es einfacher machen, die grundlegenden Prinzipien von REST einzuhalten.

REST und IoT

Angesichts der nahezu allgegenwärtigen Verbreitung von REST APIs und der explosionsartigen Zunahme von Geräten im Internet der Dinge (Internet of Things, IoT) scheint dies eine perfekte Kombination zu sein. Es werden kompakte Formate auf der Grundlage von JSON, EXI und CBOR (Concise Binary Object Representation), einem JSON-Ableger, verwendet, und RESTful APIs sind ebenfalls kompakt.

In einem IoT-System arbeiten die Geräte in einer Client-Server-Beziehung. In dieser Beziehung können die Geräte als Client, Server oder beides fungieren. Geräte können als Client fungieren und den Kontakt mit einem Verzeichnis, zum Beispiel dem CoRE Resource Directory, oder einem anderen Gerät herstellen. Geräte können auch als Ursprungsserver oder -ressource fungieren, zum Beispiel als Sensor, der Temperaturen oder andere Statusanzeigen liefert.

Wie bereits erwähnt, sollten jedoch alle Client-Server-Operationen, die REST verwenden, zustandslos sein, und jede erforderliche Zustandsverwaltung sollte auf dem Client und nicht auf dem Server stattfinden. Das bedeutet, dass alle Nachrichten alle für die Verarbeitung erforderlichen Informationen enthalten müssen, unabhängig von früheren Nachrichten.

Zwei Dinge haben dazu beigetragen, dass REST bei IoT-Entwicklern so beliebt geworden ist. Erstens ist REST bereits weit verbreitet, gut bekannt und reproduzierbar. Zweitens sind die von IoT-Ressourcen angeforderten Daten in der Regel einfach, wie zum Beispiel der aktuelle Messwert eines Sensors, und statisch, wie zum Beispiel die Gerätebeschreibung eines Herstellers, so dass REST, das das HTTP des Internets nutzt, eine natürliche Lösung darstellt.

Entwicklung von REST

REST wurde erstmals von dem Informatiker Roy Fielding in seiner Dissertation an der University of California, Irvine, aus dem Jahr 2000 mit dem Titel Architectural Styles and the Design of Network-based Software Architectures geprägt.

In Kapitel 5 der Dissertation Representational State Transfer (REST) beschrieb Fielding seine Vorstellungen darüber, wie verteilte Hypermedia-Systeme am besten zu gestalten sind. Fielding stellte eine Reihe von Randbedingungen fest, die beschreiben, wie sich REST-Systeme verhalten sollten. Diese Bedingungen werden als REST-Constraints bezeichnet, wobei vier der wichtigsten Constraints im Folgenden beschrieben werden:

• Verwendung einer einheitlichen Schnittstelle (UI). Wie bereits erwähnt, sollten Ressourcen in REST-basierten Systemen durch eine einzige URL eindeutig identifizierbar sein, und nur durch die Verwendung der zugrunde liegenden Methoden des Netzwerkprotokolls, wie DELETE, PUT und POST mit HTTP, sollte es möglich sein, eine Ressource zu manipulieren.
• Client-Server-basiert. Bei REST-Systemen sollte es eine klare Abgrenzung zwischen Client und Server geben. So sind beispielsweise die Benutzeroberfläche und die Erstellung von Anfragen die Domäne des Clients. Datenzugriff, Workload-Management und Sicherheit sind hingegen Sache des Servers. Diese Trennung ermöglicht eine lose Kopplung zwischen Client und Server, und beide können unabhängig voneinander entwickelt und verbessert werden.
• Zustandslose Operationen. Alle Client-Server-Operationen sollten zustandslos sein, und jede erforderliche Zustandsverwaltung sollte auf dem Client und nicht auf dem Server stattfinden.
• RESTful-Ressourcen-Caching. Die Möglichkeit, Ressourcen zwischen Client-Aufrufen zwischenzuspeichern, ist eine Priorität, um Latenzzeiten zu verringern und die Leistung zu verbessern. Daher sollten alle Ressourcen eine Zwischenspeicherung ermöglichen, es sei denn, es wird ausdrücklich darauf hingewiesen, dass dies nicht möglich ist.