© Spectral-Design/Shutterstock.com
Entwickler Magazin
Potenziale der Erstellung von RESTful APIs

Wie man REST (nicht) richtig macht

„Wir machen REST“ ist die ewig wiederkehrende Antwort auf die Frage nach dem Datentransfer zwischen Client und Server im Webkontext. REST (Representational State Transfer) scheint damit allgegenwärtig zu sein, immerhin ist REST ja auch ein allgemein akzeptiertes und modernes Schlagwort. Das birgt aber so manche Tücken.

Paul Reiser, Fabian Volkert, Arne Koschel, Holger Tiemeyer


Die Absurdität der pauschalen Aussage, dass REST die Antwort auf die Frage nach dem Datentransfer ist, manifestiert sich während der Analyse des betreffenden Systems oder der Anforderungen daran. Es existiert eine Vielzahl an unterschiedlichen Ausprägungen, die als RESTful bezeichnet werden. HTTP-basierte Interfaces werden pauschal als RESTful aufgefasst, weil sie zum Teil mit selbsternannten RESTful-API-Beschreibungssprachen dokumentiert wurden. Der Höhepunkt der Widersinnigkeit wird in einigen wenigen Fällen in der Gleichsetzung von REST mit JSON erreicht.

Dieser Artikel greift das grundlegende Missverständnis über RESTful APIs und HTTP-Interfaces auf und erläutert die nicht ausgeschöpften Möglichkeiten der Erstellung von RESTful APIs. Die Auffassung, das Web sei ein globales, verteiltes System, das gut skaliert einer losen Kopplung von Komponenten folgt und Funktionalitäten über Service-Grenzen hinweg miteinander verbindet, ist eine Perspektive, die Roy Fielding mit der Einführung des REST-Architekturstils in seiner Dissertation im Jahr 2000 verfolgte [1]. Er nahm damit enormen Einfluss auf die vom W3C publizierte Beschreibung des Webs („Architecture of the World Wide Web“ [2]), in der die Datenformate, Informationsbeschaffung und -speicherung konzeptionell beschrieben sind.

Fieldings Perspektive erweitert dieses Konzept um Bedingungen (Constraints), die dazu führen, dass das Web zur Ausführung von Aufgaben (Tasks) benutzt werden kann. Innerhalb eines verteilten Systems können demnach Aufgaben ausgeführt werden, indem durch den Aufruf einer Transition das System von einem Zustand in einen darauffolgenden Zustand überführt wird. Mit einer Transition ist die im jeweiligen Kontext auszuführende Aufgabe verbunden.

Abbildung 1 zeigt beispielhaft die Zustände eines Benutzers in einem System. Ein initial angelegter Benutzer kann durch die Transition save in den Folgezustand Inital, saved überführt werden. Mit diesem Zustandsübergang ist die Aufgabe des Speicherns, zum Beispiel in einer Datenbank, verknüpft. Der erste Log-in des Benutzers (Transition first login) aktiviert diesen im System (Überführung in den Zustand Active). An diesem Übergang kann zum Beispiel eine Aufgabe erfolgen, die nur einmalig bei dem ersten Log-in ausgeführt wird; beispielsweise das Abspielen eines Erste-Schritte-Videos. Ein solcher Zustandsautomat kann für jede Entität im System im Vorfeld spezifiziert werden, sofern die Zustände der jeweiligen Entität bekannt sind.

Abb. 1: Beispielhaf...

Entwickler Magazin
Potenziale der Erstellung von RESTful APIs

Wie man REST (nicht) richtig macht

„Wir machen REST“ ist die ewig wiederkehrende Antwort auf die Frage nach dem Datentransfer zwischen Client und Server im Webkontext. REST (Representational State Transfer) scheint damit allgegenwärtig zu sein, immerhin ist REST ja auch ein allgemein akzeptiertes und modernes Schlagwort. Das birgt aber so manche Tücken.

Paul Reiser, Fabian Volkert, Arne Koschel, Holger Tiemeyer


Die Absurdität der pauschalen Aussage, dass REST die Antwort auf die Frage nach dem Datentransfer ist, manifestiert sich während der Analyse des betreffenden Systems oder der Anforderungen daran. Es existiert eine Vielzahl an unterschiedlichen Ausprägungen, die als RESTful bezeichnet werden. HTTP-basierte Interfaces werden pauschal als RESTful aufgefasst, weil sie zum Teil mit selbsternannten RESTful-API-Beschreibungssprachen dokumentiert wurden. Der Höhepunkt der Widersinnigkeit wird in einigen wenigen Fällen in der Gleichsetzung von REST mit JSON erreicht.

Dieser Artikel greift das grundlegende Missverständnis über RESTful APIs und HTTP-Interfaces auf und erläutert die nicht ausgeschöpften Möglichkeiten der Erstellung von RESTful APIs. Die Auffassung, das Web sei ein globales, verteiltes System, das gut skaliert einer losen Kopplung von Komponenten folgt und Funktionalitäten über Service-Grenzen hinweg miteinander verbindet, ist eine Perspektive, die Roy Fielding mit der Einführung des REST-Architekturstils in seiner Dissertation im Jahr 2000 verfolgte [1]. Er nahm damit enormen Einfluss auf die vom W3C publizierte Beschreibung des Webs („Architecture of the World Wide Web“ [2]), in der die Datenformate, Informationsbeschaffung und -speicherung konzeptionell beschrieben sind.

Fieldings Perspektive erweitert dieses Konzept um Bedingungen (Constraints), die dazu führen, dass das Web zur Ausführung von Aufgaben (Tasks) benutzt werden kann. Innerhalb eines verteilten Systems können demnach Aufgaben ausgeführt werden, indem durch den Aufruf einer Transition das System von einem Zustand in einen darauffolgenden Zustand überführt wird. Mit einer Transition ist die im jeweiligen Kontext auszuführende Aufgabe verbunden.

Abbildung 1 zeigt beispielhaft die Zustände eines Benutzers in einem System. Ein initial angelegter Benutzer kann durch die Transition save in den Folgezustand Inital, saved überführt werden. Mit diesem Zustandsübergang ist die Aufgabe des Speicherns, zum Beispiel in einer Datenbank, verknüpft. Der erste Log-in des Benutzers (Transition first login) aktiviert diesen im System (Überführung in den Zustand Active). An diesem Übergang kann zum Beispiel eine Aufgabe erfolgen, die nur einmalig bei dem ersten Log-in ausgeführt wird; beispielsweise das Abspielen eines Erste-Schritte-Videos. Ein solcher Zustandsautomat kann für jede Entität im System im Vorfeld spezifiziert werden, sofern die Zustände der jeweiligen Entität bekannt sind.

Abb. 1: Beispielhaf...

Neugierig geworden?


   
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang