Start - Publikationen - Wissen - TOGAF - Impressum -

Einleitung


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:

  • visibility: Um einen Request zu verstehen und analysieren zu können reicht allein der Request aus. Die Historie der Anfrage muss nicht bekannt sein. Man erleichtert der Netzwerkinfrastruktur wie Firewalls und Caches damit enorm die Arbeit.
  • reliability: Fehlerbehandlung wird einfacher, nach einem Serverneustart oder temporären Netzausfall kann ein Request einfach wiederholt werden.
  • scalabilty: Ein Cluster aus Servernknoten die keinen Clientzustand verwalten zeigt das beste Skalenverhalten.
Auch Nachteile werden genannt. Requests die den conversational state beinhalten sind größer und belegen damit mehr Bandbreite.

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

  • Ein einheitliches Vorgehen mit dem Ressourcen identifiziert werden - das bedeutet unter anderem, dass jede Ressource einer verteilten Anwendung eine einheitliche Identifikation (einen Namen, einen Pfad, eine UID etc.) besitzt.
  • Ein einheitliches Vorgehen mit dem Ressourcen über ihre Repräsentation manipuliert werden
  • self descriptive messages - das hießt die Repräsentierung einer Ressource kann allein mit den Informationen der Nachricht erfolgen. Man denke hier an die mime-types eines HTTP Responses.
  • "hypermedia as the engine of application state" - Hier ist gemeint: die Repräsentationen einer Ressource liefert gleichzeitig potenziell mögliche Zustandsänderungen dieser Ressource. Der Client wählt dann lediglich eine dieser Alternativen, er muss dabei wenig oder garnicht internes Wissen über die Ressourcen vorrätig haben. Das ist wiederum die Voraussetzung dafür, dass das Prinzip 1 im oben genannten Sinne umgesetzt werden kann.
Mir scheint, das ist das entscheidende Architekturprinzip. Die bisher genannten Prinzipien treffen im Grunde genommen nur auf das HTTP-Protokoll zu, wenn es konform zur Spezifikation benutzt wird. Die allermeisten HTTP-basierten Protokolle und Services sind das nicht. Das disqualifiziert viele Frameworks und Anwendungen als nicht REST konform. Das trifft zum Beispiel auf Webservices zu, selbst wenn sie auf SOAP via HTTP basieren.

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 heute


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.

Referenzen


Architectural Styles and the Design of Network-based Software Architectures, Dissertation von Roy Thomas Fielding

copyright © 2002-2018 | Dr. Christian Dürr | prozesse-und-systeme.de | all rights reserved