Representational State Transfer

Grundidee und Bedeutung

Representational State Transfer (REST) ist ein Paradigma für die Softwarearchitektur verteilter Systeme, besonders für Webservices. Es abstrahiert Struktur und Verhalten des World Wide Web und dient vor allem der Maschine-zu-Maschine-Kommunikation. Sein wichtigstes Unterscheidungsmerkmal gegenüber anderen Architekturstilen ist eine einheitliche Schnittstelle.

REST betrachtet Informationen als Ressourcen. Ein URI (Uniform Resource Identifier) bezeichnet ausschließlich den Namen oder Ort einer Ressource, nicht eine darauf anzuwendende Funktion. Die Ressource kann durch verschiedene Medientypen repräsentiert werden, beispielsweise HTML, JSON oder XML. Ein Zustandsübergang einer Anwendung entsteht durch die Übertragung von Daten, die den nächsten Zustand repräsentieren.

REST nutzt vorhandene Web-Infrastruktur wie Web- und Application-Server, HTTP-fähige Clients, Parser und Sicherheitsmechanismen. Ein Dienst, der unveränderte Inhalte über HTTP bereitstellt, kann bereits REST-konform sein. Auch dynamische Inhalte können dem Paradigma entsprechen, wenn ihre Darstellung ein stabiles, automatisch verarbeitbares Format besitzt. Als Beispiel nennt der Artikel eine Webseite, die stets die aktuelle Uhrzeit im gleichen Format ausgibt.

REST entwickelte sich aus dem 1994 von Roy Fielding entworfenen HTTP Object Model. Fielding veröffentlichte den REST-Architekturstil 2000 in seiner Dissertation.

Architekturprinzipien

Fielding beschreibt sechs Eigenschaften eines REST-Dienstes, ohne eine bestimmte technische Implementierung vorzuschreiben:

• Client-Server: Der Server stellt Dienste bereit, die ein Client anfordert. Beide Seiten können unabhängig entwickelt werden. Das erleichtert besonders die Skalierung der Server.

• Zustandslosigkeit: Jede Nachricht muss alle Informationen enthalten, die zu ihrem Verständnis und zur Verarbeitung nötig sind. Server und Anwendung speichern zwischen zwei Nachrichten keine Sitzungs- oder Anwendungszustände. Dadurch lassen sich Anfragen bei der Lastverteilung auf beliebige Maschinen verteilen, und die Ausfallsicherheit steigt. In der Praxis halten viele HTTP-Anwendungen Zustandsinformationen mit Cookies oder anderen Techniken auf der Client-Seite. Nachteilig ist, dass jede Anfrage die benötigten Informationen erneut übertragen muss, was die Netzwerkleistung verschlechtern kann.

• Caching: Wiederverwendbare Antworten sollen zwischengespeichert werden, denn eine nicht erforderliche Anfrage ist die schnellste Anfrage. Dabei besteht das Risiko, dass ein Client veraltete Daten aus dem Cache verwendet.

• Einheitliche Schnittstelle: Sie soll den Zugriff vereinfachen und umfasst Adressierbarkeit, Repräsentationen zur Veränderung von Ressourcen, selbstbeschreibende Nachrichten und HATEOAS.

• Mehrschichtige Systeme: Ein Client muss nur die sichtbare Schnittstelle kennen; dahinterliegende Ebenen bleiben verborgen. Das vereinfacht die Architektur, verbessert die Skalierbarkeit und erlaubt eine Abgrenzung durch Firewalls. Caches an Schichtgrenzen können die Effizienz erhöhen.

• Code on Demand: Diese Eigenschaft ist optional. Der Server kann dem Client bei Bedarf Code zur lokalen Ausführung übertragen, beispielsweise JavaScript zusammen mit einer HTML-Repräsentation.

Ressourcen und HTTP-Methoden

Jede durch einen URI bezeichnete Information gilt als Ressource. Ein REST-konformer Dienst besitzt eine eindeutige Adresse in Form eines URL (Uniform Resource Locator). Einheitliche Adressen erleichtern den Zugriff verschiedener Clients und die Wiederverwendung eines Dienstes in einem Mashup.

Eine Ressource kann in unterschiedlichen Sprachen oder Formaten wie HTML, JSON und XML dargestellt werden. Die übertragene Repräsentation enthält die notwendigen Informationen zur Veränderung der Ressource, muss aber nicht der internen Speicherung entsprechen. Beispielsweise kann ein Server JSON austauschen, obwohl er die Daten intern in mehreren Spalten einer relationalen Datenbank speichert. Der Zustand einer Ressource soll ausschließlich über eine solche Repräsentation verändert werden. Nachrichten sollen außerdem selbstbeschreibend sein und dafür standardisierte Methoden verwenden.

REST verlangt kein bestimmtes Protokoll. In der Praxis werden jedoch fast ausschließlich die zustandslosen Anwendungsschicht-Protokolle HTTP und HTTPS eingesetzt. Bei HTTP bestimmt die Methode die gewünschte Operation:

• GET fordert eine Ressource an und darf außer dem Abruf keine weiteren Effekte haben; die Methode ist daher „sicher“. • POST legt eine neue Unterressource unterhalb einer vorhandenen Ressource an. Weil die neue Ressource noch keinen URI besitzt, wird zunächst die übergeordnete Ressource adressiert. POST kann auch Operationen abbilden, für die keine andere Methode passt. • PUT legt die adressierte Ressource an oder verändert sie, falls sie bereits existiert. • PATCH verändert einen Teil einer Ressource; Nebeneffekte sind erlaubt. • DELETE löscht eine Ressource. • HEAD fordert Metadaten zu einer Ressource an. • OPTIONS ermittelt die für eine Ressource verfügbaren Methoden. • CONNECT leitet eine Anfrage durch einen TCP-Tunnel, meist für HTTPS über einen HTTP-Proxy. • TRACE gibt die Anfrage so zurück, wie sie beim Zielserver eintrifft, und kann Änderungen durch Proxyserver sichtbar machen.

GET, HEAD, PUT und DELETE müssen gemäß HTTP-Spezifikation idempotent sein: Das wiederholte Senden derselben Anforderung hat keine andere Wirkung als ein einmaliger Aufruf. Weitere mögliche Methoden sind COPY, MOVE, MKCOL, LOCK und UNLOCK aus WebDAV sowie LINK und UNLINK aus RFC 2068. Bei UDP kann statt HTTP das Protokoll CoAP aus RFC 7252 eingesetzt werden; dort weichen die Bedeutungen von GET, POST, PUT und DELETE leicht ab.

Navigation mit HATEOAS und Reifegrade

HATEOAS bedeutet „Hypermedia as the Engine of Application State“ und gilt laut Fielding als wichtigste Eigenschaft der einheitlichen Schnittstelle. Der Client navigiert ausschließlich über URLs, die der Server bereitstellt. Diese Verweise erscheinen beispielsweise als „href“- oder „src“-Attribute in HTML oder als definierte Attribute beziehungsweise Elemente in JSON und XML. Ein HATEOAS-konformer Dienst lässt sich als endlicher Automat verstehen: Die angebotenen URIs bestimmen, welche Zustandsübergänge möglich sind.

Dadurch bleiben Client und Server lose gekoppelt, und die Schnittstelle kann verändert werden. Anders als bei SOAP ist kein dauerhaft fixiertes, in einem WSDL-Dokument beschriebenes Interface nötig. Auch Registrierungsdatenbanken, wie sie etwa bei Remote Function Call vorkommen, werden nicht benötigt. Standards zur Darstellung von HATEOAS sind JSON API, JSON-LD und Hydra, Collection+JSON sowie Siren.

Das Konto-Beispiel zeigt das Prinzip: Eine GET-Anfrage an „/accounts/123abc“ liefert Kontodaten und die aktuell möglichen Aktionen als Links. Bei einem Guthaben von 100,0 EUR enthält die Antwort Links zum Einzahlen, Abbuchen, Überweisen und Kündigen. Bei einem Kontostand von −100,0 EUR wird nur noch der Link zum Einzahlen angeboten. Der Server teilt dem Client damit nicht nur Daten, sondern auch die im jeweiligen Zustand zulässigen nächsten Schritte mit.

Das Richardson Maturity Model (RMM) von Leonard Richardson bewertet, wie strikt ein Service REST umsetzt. Level 0 nutzt XML-RPC oder SOAP, einen einzigen URI und meist nur POST. Level 1 unterscheidet Ressourcen und URIs, verwendet aber weiterhin nur eine HTTP-Methode. Level 2 verwendet mehrere Ressourcen, URIs und HTTP-Methoden. Level 3 ergänzt HATEOAS und damit die Navigation über Hypermedia.

Sicherheit, Versionierung und Abgrenzung

Bei REST identifiziert der URI die Ressource. Der HTTP-Header kann unter anderem Methode, gewünschtes Rückgabeformat und Authentifizierungsdaten enthalten. Authentifizierung ist beispielsweise durch Prüfung der IP-Adresse, HTTP-Authentifizierung, TLS/HTTPS-Zertifikate oder tokenbasierte Verfahren wie HMAC, OAuth, JSON Web Token und OpenID möglich. REST definiert im Gegensatz zu SOAP mit WS-Security keine eigene Verschlüsselung. Sicherheitskritische Nachrichten werden deshalb über ein verschlüsseltes Transportprotokoll wie HTTPS übertragen. Firewalls können HTTP-Methoden verstehen, protokollieren und filtern, etwa sämtliche externen PUT-Anfragen ablehnen.

Ein REST-Service kann über die DNS-Adresse, den URL-Pfad oder den HTTP-Header versioniert werden. Eine Version im Hostnamen, etwa „v1.api.example.com“, verursacht meist hohen DNS-Verwaltungsaufwand und wird kaum verwendet. Am gebräuchlichsten ist die Version im URL-Pfad, beispielsweise „/api/v1/customer/1234“. Alternativ kann die Version im Accept-HTTP-Header stehen.

Nach Veröffentlichung einer neuen Version soll die alte Schnittstelle für eine Übergangszeit verfügbar bleiben. Ein Warning-HTTP-Header kann einen Client darüber informieren, dass ein Endpunkt veraltet ist und wann er abgeschaltet wird. Der Client sollte diese Warnung in einem Log und einer OpsDB protokollieren. Ein HTTP-Redirect, beispielsweise mit dem Status „302 Found“, kann von der alten zur neuen Adresse führen. Vor der Abschaltung sollte durch Monitoring geprüft werden, ob der alte Endpunkt noch genutzt wird; seltene, etwa quartalsweise Zugriffe müssen dabei berücksichtigt werden.

REST ist ein Programmier- und Architekturparadigma, das mit unterschiedlichen Mechanismen umgesetzt werden kann. Es nutzt typischerweise mehrere HTTP-Methoden und URIs zur Identifikation konkreter Ressourcen. SOAP verwendet dagegen im Wesentlichen POST und wurde häufig RPC-basiert aufgebaut. Als Nachteile von SOAP nennt der Artikel einen großen Anteil an Meta- gegenüber Nutzdaten, das rechenintensive Erzeugen von XML-Nachrichten und zahlreiche schwer überschaubare Substandards. Die engeren REST-Vorgaben unterstützen dagegen gut strukturierte Dienste und sogenannte Clean URLs.