Was ist REST? Teil 2: RESTful-Interfaces

Was ist REST? Teil 2: RESTful-Interfaces

RESTful-Architektur: Revisiting

In seiner Dissertation definiert Roy Fielding eine RESTful-Architektur als Uniform (einheitliches Interface) – Layered (mehrschichtiges System) – Client-Cache (zustandlos mit Session State auf dem Client) –Stateless-Server (zustandslos ohne Application State auf dem Server). Eine detaillierte Betrachtung hierzu findet sich in Teil 1 dieser Serie.
Fielding setzt Uniform (also einheitliches Interface) nicht zufällig an die erste Stelle; für ihn ist es das wichtigste Unterscheidungsmerkmal einer RESTful-Architektur.

Das einheitliche (RESTful-)Interface zeichnet sich durch die folgenden vier Eigenschaften (constraints) aus:

  • Identifikation von Ressourcen (identification of resources)

  • Manipulation von Ressourcen durch Repräsentationen (manipulation of resources through representations)

  • Selbstbeschreibende Nachrichten (selfdescriptive messages)

  • Hypermedia as the engine of application state

Identifikation von Ressourcen

Eine Ressource ist eine beliebige Information, welche die Clients über eine Hyperlink-Referenz abrufen können. Fielding schreibt dazu in seiner Dissertation:

(…) any concept that might be the target of an author’s hypertext reference must fit within the definition of a resource.

Verwaltet ein Server z. B. eine Kundendatenbank, so könnte dieser Server KUNDE sowie LISTE VON KUNDEN durchaus als Ressourcen anbieten. Jede Ressource kann über einen eindeutigen Identifier angesprochen werden. Im Kontext eines verteilten Hypermedia Systems (Web) fungiert ein Link als Ressourcen-Identifier. Im heutigen Web würde man die Identifier wie folgt aufbauen:

  • KUNDE: pfad/kunden/[kunden_id]
  • LISTE VON KUNDEN: pfad/kunden

Da der Identifier eine Ressource eindeutig identifiziert, soll dieser statisch sein. Für die Kundennummer 123 soll der Identifier immer pfad/kunden/123 sein. Eine Ressource kann im Gegensatz dazu dynamisch sein. Das bedeutet, dass die Attribute einer Ressource sich durchaus ändern können. Lebt der Kunden mit der Kundennummer 123 zum Zeitpunkt A in Hamburg und zum Zeitpunkt B in Berlin, so würde der Client zum Zeitpunkt A und B unterschiedliche Ausprägungen dieser Ressource bekommen (das Attribut „Standort“ würde sich unterscheiden). Fielding spricht in diesem Zusammenhang auch von unterschiedlichen Zuständen einer Ressource.

Das Schaubild zeigt unterschiedliche Zustände einer Ressource

Manipulation von Ressourcen durch Repräsentationen

Wenn ein Client über den Link (also Identifier) eine Ressource anfragt, so liefert der Server in der Response nicht die Ressource selbst, sondern ihre Repräsentation. Eine Repräsentation ist laut Fielding eine Sequenz von Bytes sowie von Metadaten, welche diese Bytes beschreiben. In diesem Zusammenhang ist die Repräsentation eine Art Datenformat einer Ressource. Der Server kann mehrere Repräsentationen einer Ressource haben. Beim Request kann der Client dem Server mitteilen, welche Repräsentation (also welches Datenformat) er in der Response erwartet. Das nachfolgende Beispiel demonstriert, wie der Server für unterschiedliche Clients unterschiedliche Repräsentationen der Ressource KUNDE ausliefert: XML und JSON. Die Clients benutzen den HTTP Header CONTENT-TYPE, um dem Server die gewünschte Repräsentation mitzuteilen. Für dieses „Aushandeln“ des richtigen Formates führt Fielding den Begriff „Content Negotiation“ ein.

Das Schaubild veranschaulicht den Zugriff der Clienten auf die Repräsentationen

Clients können die Ressourcen nicht nur anfragen, sondern auch ändern. Auch hier operieren die Clients nicht auf den Ressourcen direkt, sondern auf ihren Repräsentationen. Dieses Prinzip hat den Vorteil, dass die Clients nicht die technische Implementierung, sondern lediglich die Repräsentation „technisch verstehen“ müssen.

Die beiden oben beschriebenen Eigenschaften waren ausschlaggebend für die Namensgebung von REST: REpresentational State Transfer. Es geht also darum, dass eine Ressource unterschiedliche Zustände haben kann und dass Client und Server die Repräsentationen dieser Zustände austauschen.

Selbstbeschreibende Nachrichten

Eine RESTful-Architektur ist mehrschichtig (layered): sie besteht aus mehreren Komponenten, welche miteinander kommunizieren und hierbei unterschiedliche Aufgaben erfüllen. In der Kommunikation sind nicht nur Client (stellt Anfrage via Request) und Server (liefert Antwort via Response), sondern auch spezielle Komponenten, welche die Requests und Responses weiterleiten. Fielding spricht in diesem Zusammenhang von Gateways und Proxies. Eine selbstbeschreibende Nachricht beinhaltet alle Informationen, welche für ihre Prozessierung durch Client, Server, Proxy und Gateway erforderlich sind.

Im Kontext von HTTP besitzt jeder Request eine Reihe von Headern, welche bestimmte Eigenschaften einer HTTP-Nachricht beschreiben. In einer HTTP-basierten Kommunikation nutzt jede beteiligte Komponente ausschließlich solche HTTP Header, welche für die Verarbeitung dieser Nachricht erforderlich sind und somit der Aufgabe dieser Komponente entsprechen. So weiß der Client allein anhand des Content-Types einer Nachricht, welcher Parser für die Prozessierung zu verwenden ist (z. B. XML oder JSON).

Hypermedia as the engine of application state

Hypermedia as the engine of application state (üblicherweise als HATEOAS abgekürzt) ist die am meisten missverstandene Eigenschaft eines REST-Interfaces. Kein Wunder: Fielding erwähnt HATEOAS in seiner Dissertation, liefert jedoch keinerlei Erklärungen dafür. In einem Blog-Beitrag beklagt Fielding das fehlende Verständnis für HATEOAS und betont ihre Bedeutung:

What needs to be done to make the REST architectural style clear on the notion that hypertext is a constraint? In other words, if the engine of application state (and hence the API) is not being driven by hypertext, then it cannot be RESTful and cannot be a REST API.

Unter HATEOAS versteht Fielding die Art und Weise, wie Clients ein REST-Interface nutzen. Der Client soll nämlich ein REST-Interface über einen allgemein bekannten Einstiegspunkt „betreten“. Der Server teilt dem Client mittels Hypermedia mit, welche Ressourcen die Schnittstelle anbietet und welche Aktionen für diese Ressourcen möglich sind. Der Client führt Aktionen aus und ändert dadurch den Status einer Ressource (um präziser zu sein: den Status der Repräsentation einer Ressource).

Die nachfolgende Abbildung zeigt HATEOAS in Aktion. Als Beispiel verwenden wir die in den vorangegangenen Abschnitten eingeführte Kundendatenbank. Der Client ruft initial die Liste aller Kunden auf und nutzt dabei den Identifier /kunden. Der Server liefert in der Response eine Kundenliste, bestehend aus zwei Einträgen: Kunde mit ID=123 und Kunde mit ID=456. Jeder dieser Einträge enthält ein Link auf den jeweiligen Kunden (rel=“self“) und seine Bestellungen (rel=“bestellungen“). Der Client möchte wissen, welche Bestellungen der Kunde mit ID=123 abgegeben hatte und ruft /kunden/123/bestellungen auf. Der Server liefert die Bestellungen mit ID=1 zurück. Die Response enthält neben der Referenz auf die Bestellung selbst noch zwei weitere Links: der Client kann Details aufrufen oder die Bestellung stornieren. Der Server teilt dem Client nach jeder Anfrage mit, welche weitere Aktionen möglich sind. Der Client kann über das Interface explorativ navigieren und muss sich die Links nicht im Vorfeld merken.

Die Abbildung zeigt die Funktionsweise von HATEOS

Zusammenfassung

Ein RESTful Interface zeichnet sich nach Fielding dadurch aus, dass Clients Ressourcen durch die Repräsentationen manipulieren können. Die technischen Implementierungsdetails von Ressourcen bleiben für die Clients verborgen: Dies ist eine wichtige Voraussetzung für die lose Kopplung zwischen Client und Server. Weitere charakteristische Merkmale sind selbstbeschreibende Nachrichten sowie insbesondere HATEOAS. Bei HATEOAS geht es um den Einsatz von Hypermedia bei der Kommunikation zwischen Client und Server. Das Erfüllen von HATEOAS ist eine wichtige Voraussetzung jedes RESTful Interfaces.

Autor: Nicolai Zaidman

Mehr zum Thema

WIR SIND FÜR SIE DA!

Mit Q_PERIOR steht Ihnen ein starker Partner zur Seite.
Wir freuen uns auf Ihre Herausforderung!