Representational State Transfer (REST) ist ein häufig zitierter Begriff. Er bezeichnet einen Architekturstil für netzwerkbasierte Anwendungen und ist in der Dissertation von Roy Thomas Fielding im Jahr 2000 geprägt worden. REST wird auch oft im falschen Zusammenhang benutzt, insbesondere ist nicht jedes HTTP basierte Stück Software automatisch REST konform. Dieser Artikel versucht diesbezüglich Klarheit zu schaffen.
In der Originalarbeit erfolgt zunächst eine architekturelle Analyse, warum das World Wide Web so erfolgreich skaliert. Dabei wird klargestellt, dass es alles andere als selbstverständlich ist, dass Milliarden Informationen weltweit verteilt Millionen Nutzern jederzeit zur Verfügung stehen. Offenbar muss es Architekturprinzipien im World Wide Web geben, die diese erstaunlichen Eigenschaften (Zuverlässigkeit, Skalierbarkeit, Schnelligkeit) ermöglichen. Aus dieser Analyse leitet der Autor Implikationen für netzwerkbasierte Anwendungen ab, die ähnliche Eigenschaften besitzen sollen. Darauf aufbauend formuliert er einen Architekturstil, der diese Implikationen berücksichtigt: REST.
Die Architekturprinzipien bei REST
Prinzip 1: Client - Server Architektur
Gemeint ist damit die Trennung der Belange der Darstellung von Informationen von den Belangen der Datenhaltung. Diese Trennung wird möglich über eine entsprechende Standardisierung der Kommunikation und erlaubt die unabhängige Behandlung der Belange am Client und am Server. Die Technologiezyklen von Client und Server werdend dadurch entkoppelt. Man versteht dieses Architekturprinzip vielleicht am besten, wenn man sich einmal das Gegenteil im heutigen Internet vorstellt und annimmt, dass jeder Webserver einen eigenen Client benötigte.
Prinzip 2: Stateless
Weder der Zustand der Ressourcen im Server noch die Kommunikation zwischen Client und Server (der conversational state) sind zustandslos - es sein denn es ist von trivialen Anwendungen die Rede. Gemeint ist, dass der conversational state nicht serverseitig verwaltet wird. Damit muss der conversational state vom Client gehalten werden. In jeder Anfrage stecken dann notwendigerweise alle Informationen um einen Request auszuführen. Dieses Vorgehen hat einige Vorteile:
Prinzip 3: Cache
Ressourcen werden als cachebar gekennzeichnet. Auf diese Weise können Request unter Umständen ganz oder teilweise ohne Serverkommunikation bedient werden da Clients und Proxy-Instanzen in der Lage sind, in der Vergangenheit gegebene Antworten auf Requests erneut zu verwenden.
Prinzip 4: Uniform Interface
Das Prinzip fordert
Prinzip 5: Layered System
Damit ist das generell anzustrebende Architekturvorgehen gemeint, übertragen auf verteilte Anwendungssysteme. In meiner Wahrnehmung ist im World Wide Web entsprechendes nicht realisiert.
Ein REST-Architekturprinzip habe ich nicht erwähnt: Code-On-Demand. Dieses Prinzip sieht die Möglichkeit, temporär clientseitg Logik zur Steuerung der schon erwähnten "engine of application state" vorzuhalten. Dieser Code ist als eine Anreicherung der hypermedial bereitgestellten Alternativen der Zustandsänderung zu werten und ist damit in gewisser Weise in das Prinzip 4.4 eingeordnet.
REST wird heute als eine Rückbesinnung auf die erfolgreiche, skalierende Architektur des Internets beim Entwurf eigener Architekturen verstanden. Der Autor hatte ursprünglich weltweit verteilte Anwendungssysteme im Fokus, die nicht unbedingt auf HTTP basieren. De facto ist aber HTTP das einzige Protokoll des Internets, das den genannten Kriterien (einigermaßen) genügt und deshalb sieht man heute REST üblicherweise als eine Art saubere HTTP-Kommunikation an. Entscheidend dabei ist, dass die generischen HTTP-Methoden dabei konform zur HTTP-Spezifikation eingesetzt und fachliche Methoden auf deren Grundlage umgesetzt werden.
Generell lässt sich feststellen, dass die Arbeit aus dem Jahr 2000 immer noch sehr frisch und aktuell zu lesen ist - in dieser Branche eine echte Leistung. Großen Dank an Roy Thomas Fielding, dass er sie online verfügbar macht.