Representational State Transfer (REST) ist ein ubiquitärer IT-Architekturstil, der regelt, wie Webserver und -clients miteinander kommunizieren. In der Welt der Softwareentwicklung ist REST eines der gebräuchlichsten Akronyme überhaupt - aber auch eines der am häufigsten missverstandenen.

In diesem Artikel lesen Sie, wie REST in der Theorie und in der Praxis (meist in Form von RESTful APIs) funktioniert.

REST in der Theorie

Software zu entwickeln, die über das Internet vertrieben werden soll, ist komplex. Zwar bietet der TCP/IP- und HTTP-Stack einen grundlegenden Mechanismus, um Daten auszutauschen, das war es dann aber auch, wenn es um Protokolle geht. Softwareentwickler mussten deshalb eigene, übergeordnete Ansätze entwickeln, wenn es darum geht, wie Ressourcen verpackt und über Web-Applikationen verteilt werden.

Mit REST schlug Roy Fielding im Jahr 2000 hierfür eine architektonische Lösung vor. Einfach zusammenfassen ließe sich das Konzept von REST wie folgt: Komponenten sollten ihren internen Zustand in einem standardisierten, implementierungsunabhängigen Format übermitteln. Anders ausgedrückt: Web-Architekturen sollten aus entkoppelten Komponenten bestehen, die über ein Standardprotokoll kommunizieren.

Doch Fielding hatte noch etwas anderes im Sinn - die Nomenklatur "Representational State Transfer" sollte ein Bild davon vermitteln, wie sich eine gut konzipierte Webanwendung verhält:

• Ein Netzwerk aus Webseiten (eine Virtual State Machine),

• in dem Benutzer sich durch die Applikation bewegen, indem sie Links (State Transitions) auswählen, was dazu führt, dass

• die nächste Seite (die den nächsten "State" der Anwendung repräsentiert) an den Benutzer übertragen und zur Nutzung gerendert wird.

In diesem Konzept spielen Webseiten und Links eine tragende Rolle. REST bezog sich ursprünglich auf Hypermedia (insbesondere HTML) und Hyperlinks. Im Wesentlichen hostet ein Web Service Ressourcen unter verschiedenen URLs und URIs. Ruft ein Benutzer eine Ressource auf, antwortet der Dienst mit einer HTML-Seite. Die Seite enthält Links, mit denen man zu anderen Ressourcen navigieren kann, und so weiter. Diese Vision unterstützt diverse Zielsetzungen guten Softwaredesigns:

• einheitliche Interfaces,

• "stateless" Komponenten,

• "cacheable" Ressourcen und

• "composable" oder "layered" Services.

RESTful APIs - REST in der Praxis

In der heutigen Praxis wird REST allerdings nicht mehr so eingesetzt, wie es ursprünglich gedacht war. In der Regel verwenden Entwickler eine HTTP-API und JSON, um die Daten für Anwendungen im Web bereitzustellen. Deshalb werden sogenannte REST-Architekturen oft auch als RESTful bezeichnet - also als etwas, das REST ähnelt.

RESTful bezeichnet folgenden Prozess: Ein Client fordert eine Ressource über eine herkömmlich formatierte URL (RESTful-API) an und erhält eine herkömmlich formatierte JSON-Antwort zurück, die die Ressource mithilfe von Key/Value-Paaren beschreibt. Das sind die charakteristischen Merkmale moderner RESTful-Webanwendungen. Dabei:

• beschreibt der URL-Pfad, wo ein Asset vorhanden ist, während

• das HTTP-Verb beschreibt, wie es verändert werden kann.

Haben Sie zum Beispiel eine API, die Daten zu Musik enthält, liegt Ihnen wahrscheinlich eine Enpunkt-URL wie musicservice/albums/1234 vor. Dabei stellt "1234" die ID eines bestimmten Assets dar. Wenn Sie eine GET-Anfrage an diesen Endpunkt stellen, erhalten Sie ein JSON-Dokument für dieses Asset zurück, wie in folgendem Beispiel.

Beispiel: Ein simpler RESTful-Service

Response:

{

id: 1234,

name: "Abbey Road",

band: "The Beatles",

year: 1969,

best_song: "Come Together"

}

In diesem Beispiel gibt der Endpunkt Daten zurück, die das Asset beschreiben. Damit wird die Anforderung erfüllt, dass der Service nichts über die Implementierung preisgibt. Die anderen Verben ermöglichen es Ihnen, die Ressource zu löschen (HTTP DELETE), sie zu verändern (HTTP PUT) oder eine neue Ressource zu erstellen (HTTP POST).

Die Struktur der API ist dabei nicht starr. Die wesentliche Regel besagt, dass GET-Requests nicht zu Änderungen führen sollten (mit anderen Worten: GET ist idempotent). Ein GET-Request an den Endpunkt musicservice/albums würde eine Liste von Alben zurückgeben. Dabei würde der Endpunkt auch Filter- und/oder Abfrageparameter als Teil der URL unterstützen, etwa:

musicservice/albums?band_name="pink_floyd"&years="1973-1980"&sort=alpha

Je komplexer die API wird, desto uneinheitlicher gestaltet sich die Darstellung (Representation) der Ressourcen. Angenommen, unsere MusicService-API unterstützt die Kennzeichnung von Alben nach Stil oder Genre über Tags. Dann könnten Sie ein Tag mit einem Album oder ein Album mit einem Tag verknüpfen - das ist bei einer RESTful-API in vielen Fällen eine Frage von Stil respektive persönlicher Vorliebe. Wichtig ist dabei lediglich, so konsistent wie möglich zu bleiben.

Eine weitere Konvention besteht darin, das HTTP-Verb POST zu verwenden, um eine neue Ressource hinzuzufügen. In diesem Fall akzeptiert die URL normalerweise ein JSON-Objekt mit den Eigenschaften des neuen Objekts. Zur Aktualisierung wird normalerweise PUT verwendet. Hier enthält die URL in der Regel die ID (/musicservice/albums/1234) und der Upload enthält das JSON mit den neuen Daten.

Services (bis hin zu Microservices) verwenden RESTful-APIs, weil sie es ermöglichen, sämtliche Arten von Tech-Stacks zu verwenden, die die REST-Konventionen übernommen haben, um ihre zugrundeliegenden Implementierungen zu verbergen. Dienste, die in diesem Stil geschrieben sind, können miteinander interagieren, um Anforderungen auf konsistente und interoperable Weise zu erfüllen.

REST vs. SOAP

In der Theorie ist REST eine Art selbstbeschreibende Servicearchitektur, bei der die Clients die Standards verstehen und der Service Daten ausgibt, die mit diesen Standards übereinstimmen. Der Client kann mehr oder weniger fortfahren, ohne etwas über die Struktur des Dienstes zu wissen. Am anderen Ende des Spektrums steht eine Art von Client-Service-Beziehung, die als Remote Procedure Call (RPC) bezeichnet wird. In diesem Modell erstellen Client und Server im Vorfeld einen formalen Vertrag, der die genaue Art ihrer Interaktion festlegt. Die Beziehung gestaltet sich dann ähnlich wie bei Procedure Calls in lokalem Code. RPC mappt die Funktionsaufrufe des Codes auf Netzwerk-Calls.

RPC bietet einige Vorteile, weil es strikter ist und sich deshalb dazu eignet, genau definierte Services und Clients zu planen. Der Nachteil des Ansatzes ist seine Starrheit: Immer wenn sich ein Client oder Server ändert, muss sich auch der jeweilige "Gegenpart" verändern, damit der Mechanismus, der den Vertrag definiert, funktioniert.

RPC und SOAP

Das bekannteste Beispiel für RPC ist wohl das Simple Object Access Protocol (SOAP). Hierbei nutzen Clients und Server XML-Definitionen, um ihre Verträge zu beschreiben. SOAP war ein wichtiger Bestandteil der SOA-Bewegung (serviceorientierte Architektur). In diesem Modell stellen Services Dienstdefinitionen zur Verfügung, die von den Clients analysiert werden können, um Fähigkeiten zu ermitteln. Diese Idee hat sich jedoch nicht wirklich durchgesetzt, insbesondere wegen ihrer Komplexität.

REST kommt theoretisch ohne eindeutige Verträge zwischen Clients und Servern aus, indem der Dienst Daten in einem Format ausgibt, das ihn selbst beschreibt. Das sorgt für mehr Flexibilität während die Leistungsfähigkeit gewahrt bleibt. So wie REST derzeit praktiziert wird, bildet es eher einen natürlichen Zwischenpunkt:

Während RPC und SOA formale Client-Server-Verträge verwenden, ist das bei REST und REST-ähnlichem JSON nicht der Fall.

REST-ähnliche Dienste (also JSON-URL-Services) maximieren die Entwicklungsgeschwindigkeit und haben deshalb auch in der Praxis den größten Anklang gefunden.

HATEOAS?

Der Nachteil des REST-ähnlichen Ansatzes ist, dass er zur Komplexität neigt. In diesem Punkt weicht er auch wesentlich von Roy Fieldings ursprünglicher Vision für REST ab. Die Komplexität des RESTful-Designs manifestiert sich am deutlichsten in modernen Web-Clients. Sie müssen in der Lage sein, JSON zu empfangen und dynamisch in interaktive Benutzeroberflächen zu verwandeln.

Das Problem dabei: Die meisten Entwickler, die REST als Architekturstil implementieren, haben eines seiner ursprünglichen Säulen aufgegeben - das HATEOAS-Prinzip. Das Akronym steht für "Hypermedia as the Engine of Application State". Es bedeutet im Wesentlichen, dass Hypermedia nur über Services ausgegeben werden sollten - eine Idee, die im direkten Gegensatz dazu steht, JSON als Distributionsmittel zu nutzen. Das Wesen von Hypermedia besteht darin, dass es sowohl die Assets als auch die Art und Weise, wie sie zu navigieren sind, beschreibt.

Jeder Webentwickler muss heute sowohl die Grundprinzipien von REST (die Theorie) als auch deren praktische Anwendung in RESTful-Applikationen und -APIs verstehen.

Dieser Beitrag basiert auf einem Artikel unserer US-Schwesterpublikation Infoworld.