Welches Potenzial steckt hinter RESTful APIs?

Von Holger Tiemeyer , 19.08.2019, 10:27
Rest

Wenn es um Datentransfers zwischen Client und Server geht, fällt häufig das Stichwort „REST“. Die Abkürzung steht für Representational State Transfer und beschreibt einen Architekturstil für verteilte Systeme. Insbesondere im Kontext von Webservices ist REST mittlerweile zu einem allgemein akzeptierten und modernen Begriff geworden.

Dabei ist die Definition alles andere als trivial. „Das ist REST!“ oder „Wir machen REST!“ sind Aussagen, die bei näherem Hinsehen oft Fragen aufwerfen. Werden beispielsweise HTTP-basierte Interfaces pauschal als RESTful bezeichnet, weil sie in Beschreibungssprachen mit einem RESTful-API-Ansatz dokumentiert wurden, ist dies per Definition nicht vollständig korrekt (siehe unten). Ebenso muss dem zu Teilen vorherrschendem Fehlschluss, REST und JSON seien gleichzusetzen, widersprochen werden. Um derartige Missverständnisse auszuräumen, widme ich mich in diesem Blogbeitrag der Definition von RESTful APIs und ihren Potenzialen insbesondere für HTTP-Interfaces.

 

Das Internet ist ein Paradebeispiel für eine RESTful Architektur

Bei REST handelt es sich vielmehr um ein weitgehend abstraktes Architekturmodell, das im Jahr 2000 vom Informatiker Roy Fielding erstmals beschrieben wurde. In seiner Dissertation Architectural Styles and the Design of Network-based Software Architectures prägte er den Begriff REST im Kontext des Webs. Das globale Web wird als ein verknüpftes System von Systemen verteilter Ressourcen definiert. Die Kommunikation findet über das Hypertext Transfer Protocol (HTTP) statt. Links vernetzen die entsprechenden Ressourcen. Eine Ressource gibt auf Anfrage des Clients ein Abbild von sich heraus und teilt dem Client innerhalb des Abbildes in Form von Links mit, was der Client durch Aufruf eines Links mit der Ressource machen darf. Hier liegt auch ein wichtiger Unterschied zum Remote Procedure Call (RPC), bei dem die Endpunkte wahlfrei aufgerufen werden können.

Innerhalb einer Analogie zu einem Zustandsautomaten kann dieses Vorgehen sehr gut dargestellt werden: Bei REST teilt die Ressource selbst dem Client mit in welchem Zustand sie sich gerade befindet und in welche möglichen Folgezustände sie durch Aufruf eines der Links überführt werden darf. Ebenso unterscheiden sich die REST-Prinzipien auch von denjenigen eines Zustandsautomaten: Denn jene schreiben nicht zwingend vor, dass die entsprechenden Transitionen und Zustände im Vorfeld definiert werden müssen, wie sie es bei einem Zustandsautomaten sind.

Hierfür prägte Fielding den Terminus Hypermedia as the engine of application state (HATEOAS). Hypermedia bezeichnet in diesem Zusammenhang die Vernetzung aller Arten von Ressourcen über (Hyper-)Links. Darin kommt eine medienneutrale Erweiterung des Begriffs Hypertext zum Ausdruck. Statusübergänge – also zum Beispiel der Aufruf einer neuen Seite – sind damit innerhalb der Repräsentation einer Ressource zu finden: Nach Abruf einer Ressource (Webseite, Daten-Entität, Dokument, uvm.) über die entsprechende URI kann der Client anhand der übermittelten Informationen innerhalb dieser entscheiden, was er mit der Ressource machen möchte. Und nur die Möglichkeiten, die die Ressource selbst mitteilt, stehen dem Client auch tatsächlich und ausschließlich zur Verfügung. HATEOAS bezeichnet also zum einen den dynamischen Übergang auf Folgezustände des verteilten Systems durch Links und HTTP-Verben und zum anderen deren Integration in die Repräsentation der jeweiligen Ressource.

Laut Fielding wird HATEOAS durch vier Grundprinzipien („constraints“) hinter REST definiert. Dazu gehört die Ressourcenidentifizierung („identification of resources“); Ressourcenänderung durch Repräsentationen („manipulation of resources through representations“) sowie selbstbeschreibende Botschaften („selfdescriptive messages“). Basierend auf dieser Definition kann es zu erheblichen Missverständnissen kommen, wenn ein jegliches HTTP-basiertes Interface sofort als REST(ful)-API bezeichnet wird. Diese unterscheiden sich nämlich je nach Erfüllungsgrad der REST-Prinzipien.

 

Ein hoher REST-Erfüllungsgrad bringt Vorteile

Auf der Basis von Fieldings Ausarbeitungen analysierte Leonard Richardson zahlreiche Web-API-Dienste und unterteilte sie in vier Kategorien, die abbilden, zu welchem Grad die REST-Prinzipien erfüllt werden:

 

  • Stufe 0: Das HTTP-Protokoll wird lediglich als Tunnel genutzt, durch den Daten zu einem Endpunkt hin übertragen werden. Dienste wie SOAP und XML-RPC fallen darunter („The Swamp of POX (Plain old XML))“.
  • Stufe 1: Der API-Dienst kann eindeutige Ressourcen-Endpunkte adressieren. Somit ist es nun möglich, mehrere Endpunkte dediziert anzusprechen (meistens mittels GET oder POST).
  • Stufe 2: Die Stufe 1 wird durch Kommunikationsmöglichkeiten unter sauberer Verwendung der HTTP-Verben ergänzt (GET, POST, PUT, PATCH, DELETE, TRACE, usw.).
  • Stufe 3: Das HATEOS-Prinzip ist vollständig implementiert. Dem Client werden aus dem System sämtliche Möglichkeiten der Zustandsänderung kommuniziert, woraufhin dieser entscheidet, welche er nutzt.

 

REST-Dienste der Stufe 3 bringen verschiedene Vorteile mit sich: Sie führen zu einer vollständigen Entkopplung von Client und Server. So obliegt es ausschließlich der Ressource dem Client mitzuteilen, was in einem jeweiligen Anwendungsfall mit der Ressource erlaubt ist. Der Client widerum besitzt keine direkte Kopplung an serverseitige Schnittstellen oder Prozesse.

Es lohnt sich insbesondere bei vielfältigen Einsatzzwecken und unterschiedlichen Clients eines Systems, die Architektur einer IT-Umgebung auf einen hohen REST-Erfüllungsgrad hin zu konzipieren.

 

Anschließend an diese grundlegende Definition von REST widmet sich mein nächster Blogbeitrag den Einsatzmöglichkeiten in unterschiedlichen Kontexten.

 

Neuen Kommentar schreiben

Ich habe die Datenschutzhinweise zur Kenntnis genommen. Ich stimme zu, dass meine Angaben und Daten zur Beantwortung meiner Anfrage elektronisch erhoben und gespeichert werden.