[Re]presentational [S]tate [T]ransfer

Einführung

Das Akronym REST steht für Representational State Transfer und beschreibt ein Programmierparadigma für verteilte Systeme. Der Schwerpunkt von REST liegt hierbei auf der Maschine-zu-Maschine Kommunikation.

Das Paradigma beschreibt eine zustandslose Kommunikation, somit kann REST mit jedem zustandslosen Protokoll realisiert werden, die häufigste Anwendung zur Realisierung von REST findet HTTP¹. Die Bezeichnung Representational State Transfer soll den Übergang von einem Zustand einer Applikation zum nächsten Zustand verdeutlichen.

Geschichte

Erstmals wurde REST in der Dissertation "Architectural Styles and the Design of Network-based Software Architectures" von Roy Thomas Fielding 2000 beschrieben, das hinter dem Paradigma steckende Grundprinzip gibt es allerdings schon seit der Einführung des WWW² von Tim Berners-Lee 1991. Dazu schreibt Fielding in seiner Dedication:

DEDICATION

[...]
And also to
Tim Berners-Lee,
for making the World Wide Web an open, collaborative project.

REST ist also schon ein altes Paradigma, das aber erst in den letzten Jahren seit ca. 2014 Anwendung in vielen Applikationen findet. Der Grund hier für ist nicht bekannt, aber nachfolgend ein Erklärungsversuch.

Es wurden Applikationen mit dem Paradigma Representational State Transfer implementiert, nur wurde das Paradigma hierbei falsch umgesetzt und hat somit nicht zum gewünschten Ergebnis geführt. Daher wurde REST wieder verworfen und es wurde auf andere Paradigmen zurückgegriffen. Diese führten dann zum gewünschten Ergebnis und haben REST verdrängt und ein wenig in Vergessenheit geraten lassen. Wodurch REST als Paradigma ca. 2014 seinen Einzug in moderne Applikationen erhalten hat, lässt sich nicht nachvollziehen. Doch gibt es heute kaum eine Applikation, die eine Schnittstelle anbietet, die dies nicht über REST konforme Ressourcen macht.

REST - Prinzipien

In seiner Dissertation fordert Fielding insgesamt sechs Prinzipien für das REST Paradigma, diese werden in den nachfolgenden Abschnitten erläutert.
Bei den Erläuterungen werde ich mich auf HTTP beziehen, da das Paradigma am häufigsten mit diesem Protokoll verwendet wird und aus diesem entstanden ist.

Client-Server

Als erstes genanntes Prinzip ist für REST eine (klassische) Client-Server Umgebung notwendig.

Zustandslosigkeit

Wie bereits in der Einführung erwähnt ist das Paradigma Representational State Transfer zustandslos. Zustandlosigkeit bedeutet, das jede Nachricht die zwischen Client und Server ausgetauscht wird alle Informationen beinhaltet die der jeweils andere zum Interpretieren der Nachricht benötigt. Es werden also keine Informationen über den Zustand zwischen zwei Nachrichten gespeichert.

Caching

Das HTTP Caching soll genutzt werden, somit werden Ressourcen die sich nicht verändert haben in einem Cache gespeichert. Dies reduziert die Last der Kommunikation, da eine Ressource nicht immer wieder neu angefragt werden muss.

Einheitliche Schnittstellen

Das Prinzip der einheitlichen Schnittstelle kann in vier Eigenschaften unterteilt werden. Die einheitliche Schnittstelle ist das größte Abgrenzungsmerkmal zu anderen Paradigmen, siehe auch Abschnitt “Abgrenzungen zu anderen Kommunikationsmechanismen.

Adressierbarkeit von Ressourcen

Ressourcen sind Informationen, die über einen URI³ gekennzeichnet wurden. Ein REST konformer Dienst hat eine eindeutige Adresse, den URL⁴ über den die Zugriffswege auf diesen Dienst vereinheitlicht werden.

Repräsentation zur Veränderung von Ressourcen

Ein REST konformer Server kann je nach Anforderung des Clients eine Ressource in unterschiedlicher Repräsentation ausliefern. Das können unterschiedliche Formate wie HTML, JSON oder XML sein, aber auch verschiedene Sprachen oder die Dokumentation der Ressource. Die Veränderung von einer Ressource soll nur über eine Repräsentation erfolgen das bedeutet, wenn wir eine Ressource im JSON Format erreichen können und diese verändern möchten, dann senden wir in diesem Fall mit dem HTTP-Verb PUT eine Repräsentation der geänderten Ressource im JSON Format.

Selbstbeschreibende Nachrichten

REST konforme Nachrichten sollen selbstbeschreibend sein, also alle Informationen enthalten die benötigt werden. Des Weiteren bedeutet dies das Standardmethoden verwendet werden, an dieser Stelle seien die HTTP-Verben genannt, diese werden im Abschnitt “Umsetzung des REST Paradigmas” beschrieben.

Hypermedia as the Engine of Application State (HATEOAS)

Nach Fielding ist dies die wohl wichtigste Eigenschaft des Representational State Transfers, HATEOAS wird im Abschnitt “Hypermedia as the Engine of Application State” beschrieben.

Mehrschichtige Systeme

Das Prinzip der Mehrschichtigkeit wird ebenso von Fielding für das REST Paradigma gefordert. Mehrschichtige Systeme ermöglichen es dem Anwender lediglich eine Schnittstelle anzubieten, die Ebenen dahinter bleiben dem Anwender verborgen. Somit kann die gesamte Architektur vereinfacht werde und es bietet Austauschbarkeit.

Als Beispiel: Wir haben eine Webanwendung die aus einem Frontend und einem Backend besteht, beide wurden mit unterschiedlichen Technologien umgesetzt, sie kommunizieren über REST Schnittstellen. Möchte man nun die Technologie im Backend ändern ist dies kein Problem, da die neue Technologie lediglich die gleichen Schnittstellen bereitstellen muss.

Code on Demand

Das Code on Demand Prinzip ist das einzige Prinzip, das Fielding nur optional fordert. Code on Demand bedeutet so viel wie Code auf Abruf.

Als Beispiel: Eine klassische Webanwendung führt den JavaScript Code nur aus wenn eine bestimmte Ressource abgerufen wird.

Hypermedia as the Engine of Application State (HATEOAS)

Als Erstes eine einfache Definition von Hypermedia:

Hypermedia sind elektronische Dokumente in Form von Hypertext, die Verbindungen (Hyperlinks) zu anderen Medien, wie Grafik, Sound oder Video enthalten. Sie ermöglichen multimediale Informationspräsentationen und –zugriffe durch Verknüpfungen.

Hypermedia auf e-teaching.org

Hypermedia as the Engine of Application State ist ein Entwurfsprinzip von REST Architekturen und bedeutet das der Client ausschließlich über die vom Server bereitgestellten URLs navigiert. Betrachtet man HATEOS abstrakt, stellt man fest, dass es einen endlichen Automaten darstellt. Die Zustandsveränderungen des Automaten erfolgen hierbei über die bereit gestellten URLs.

Umsetzung des REST Paradigmas

Die HTTP-Verben

Nachfolgend werden die sogenannten HTTP-Verben oder auch HTTP-Methoden vorgestellt und ihre Funktion innerhalb einer REST API.

GET

Durch den Aufruf einer Ressource mittels der GET Methode werden Informationen zurückgeliefert ohne das Nebeneffekte auftreten. D.h. es erfolgen keine Änderungen am Zustand auf dem Server, daher wird GET auch als sicher bezeichnet.

POST

Fügt einen neuen Datensatz hinzu. Wird eine Ressource mittels POST mit den gleichen Daten mehrfach aufgerufen, so werden auch mehrere neue Datensätze hinzugefügt.

PUT

Wird zum Aktualisieren eines Datensatzes genutzt, wird eine Ressource, mehrfach mit den gleichen Daten aufgerufen, ändert sich der Zustand des Datensatzes nur bei dem ersten Aufruf. Die PUT Methode ist idempotent.

PATCH

Ein Teil einer angebenen Ressource wird geändert, anders als bei PUT sind hier Nebeneffekte erlaubt. Diese Methode ist optional und wird nicht für CRUD⁵ Operationen benötigt.

DELETE

Wird eine Ressource mittels der DELETE Methode aufgerufen, wird der dazugehörige Datensatz gelöscht. Diese Methode ist ebenfall idempotent.

HEAD

Mit HEAD werden Metadaten zu einer Ressource angefordert.

OPTIONS

Mittels dieser Methode kann geprüft werden welche Methode bei einer Ressource zur Verfügung stehen.

CONNECT

Diese Methode dient dazu Anfragen durch einen TCP-Tunnel zu leiten.

TRACE

Die TRACE Methode gibt Anfragen so zurück, wie sie der Server erhält.

Sicherheit im REST-Paradigma

Kurz gesagt sind Sicherheitsmechanismen nicht im REST Paradigma beschrieben.

Um Sicherheit zu gewährleisten muss also das verwendete Protokoll über Sicherheitsmechanismen verfügen. Dies ist bei HTTP mit Secure geben, also HTTPS. Damit ist die Verschlüsselung der Kommunikation gewährleistet, die Authentifizierung allerdings nicht.

Um Authentifizierung in Anwendungen zu etablieren, die nach dem REST Paradigma implementiert wurden, werden sogenannte Token-basierte Authentifizierungsverfahren verwendet. Wie zum Beispiel:

• JSON Web Token (JWT)

• OAuth

• OpenID

Und weitere Verfahren die auf Authentifizierung mittels Token basieren.

Abgrenzung zu anderen Kommunikationsmechanismen

Das Representational State Trasfer Paradigma ist in erster Linie genau das, ein Paradigma. Es gibt keinen Standard der von einem Komitee vorgegeben und verabschiedet wird. Es gibt natürlich für einzelne Programmiersprachen Referenzimplementierungen mit denen man REST APIs gestalten und implementieren kann. Aber REST als solches ist ein Paradigma, ohne strikte Vorgaben.

REST kann also mit verschiedenen Mechanismen implementiert werden und Anwendungen werden nicht immer vollständig RESTful umgesetzt, dazu mehr im nachfolgenden.

Was REST von anderen Kommunikationsmechanismen unterscheidet, ist der geringe Overhead⁶ an Metadaten die ausgetauscht werden müssen, da bei REST auf eine breite Verwendung von Methoden geachtet wird.
REST kommt ohne maschinenlesbare Dokumentation aus, wie zum Beispiel WSDL. Dokumentation erfolgt für Menschen lesbar und ist bei einem guten Desgin der API teilweise überflüssig da es klare URLs gibt, welche in Kombination mit der passenden HTTP Methode den Kontext erschließen lassen.

Richardson-Reifegradmodell

Wie schon im voran gegangenen Kapitel erwähnt, es gibt keinen Standard der REST definiert. Leonard Richardson hat einen Maßstab entwickelt, mit dem definiert werden kann wie strikt bzw. wie reif ein Service nach REST ist. Das Richardson Maturity Model (RMM) oder übersetzt das Richardson-Reifegradmodell, ist eingeteilt in vier unterschiedliche Stufen angefangen bei Stufe 0.
Die Stufen bauen aufeinander auf, wobei Stufe 0 der sogenannte Swamp of POX⁷ ist und Stufe 3 ein RESTful Service.

Stufe 0

Es wird lediglich eine einzelne URI und HTTP Methode verwendet und als Protokoll dienen XML-RPC oder SOAP

Stufe 1

Es werden mehrere URIs und Ressourcen verwendet und weiterhin nur eine einzelne Methode.

Stufe 2

Es werden mehrere URIs, Ressourcen und HTTP Methoden verwendet.

Stufe 3

Die Anwendung basiert auf HATEOAS und verwendet mehrere URIs, Ressourcen, HTTP Methoden und HTTP Status Codes.

Wenn eine REST API entwickelt wird sollte das Richardson-Reifegradmodell immer berücksichtigt werden, da es eine Orientierungshilfe bei den Designentscheidungen darstellt.

Mithilfe des Reifegradmodells kann man also einen Service einstufen in hinblickt auf seine REST Umsetzung. Also wie sehr wurde das Paradigma befolgt bzw. umgesetzt, wie “Reif” ist die Anwendung.

Dazu haben sich in der Entwicklergemeinschaft drei Begriffe etabliert:

Not RESTful

REST wurde nicht umgesetzt, es werden einzelne Teile des Paradigmas verwendet. Stufe 0 - Stufe 1

Not fully RESTful

REST wurde zum Großteil umgesetzt, aber die nach Fielding wichtigste Eigenschaft HATEOAS fehlt noch. Stufe 2

Completely RESTful

Die Anwendung hat alle Forderungen von Fielding umgesetzt. Stufe 3

Fazit

Das Representational State Transfert Paradigma ist hervorragend geeignet um Architekturen skalierbar zu gestalten. Aber auch um Wartbarkeit, Erweiterbarkeit und Flexibilität in einer Architektur zu einem größten möglichen Punkt zu bringen.

Neue Anwendungen und Architekturen sollten REST immer in Erwägung ziehen, für Webservices gehört REST einfach zum “guten Ton”.

Abkürzungsverzeichnis