REST: Representational State Transfer

Das World Wide Web besteht aus weit mehr Komponenten, als Internetnutzer beim Aufruf einer Website oder -applikation wahrnehmen. So greifen beispielsweise nicht nur menschliche User, sondern auch maschinelle Benutzer auf die Daten und Inhalte verschiedenster Webprojekte zu. Die Voraussetzung ist, dass der jeweilige Betreiber sein Projekt überhaupt anderen Anwendungen zugänglich macht, indem er einen entsprechenden Webservice zur Verfügung stellt. Ein gutes Beispiel stellt der Kurznachrichtendienst Twitter dar: Dank eines entsprechenden Webservices können beliebige Anwendungen Tweets im Namen eines Twitter-Users auslesen oder gar schreiben.

Um einen solchen Webservice zu implementieren, gibt es verschiedene Techniken wie das Abfrageprotokoll Remote Procedure Call (RPC), das Netzwerkprotokoll SOAP oder auch das Programmierparadigma Representational State Transfer (REST), um das es im Folgenden geht.

Der Begriff „Representational State Transfer“ stammt aus einer von 2000 datierenden Dissertation von Roy Fielding, einem der Hauptentwickler zahlreicher Webstandards. Er beschreibt in abstrahierter Form die Architektur, die dem World Wide Web (HTTP-Protokoll, HTML- und XML-Parser, Web- und Application-Server etc.) zugrunde liegt. Prinzipiell ist die REST-Architektur allerdings nicht von spezifischen Protokollen abhängig. Ihr zentrales Konzept sind Ressourcen, die nach Fielding folgende Anforderungen erfüllen müssen:

• Adressierbarkeit: Jede Ressource, z. B. eine Bestellung, ein Produkt oder ein Artikel, muss über einen Unique Resource Identifier (URI) identifiziert werden können.

• Einheitliche Schnittstelle: Auf jede Ressource muss einfach und einheitlich mithilfe von Standardmethoden zugegriffen werden können. Beispiele sind HTTP-Methoden wie „GET“, „POST“ oder „PUT“.

• Client-Server-Struktur: Generell gilt das Client-Server-Prinzip, nach dem ein Server einen Dienst zur Verfügung stellt, der bei Bedarf von einem Client angefordert werden kann.

• Zustandslosigkeit: Die Kommunikation zwischen Server und Clients ist zustandslos. Das heißt, dass alle ausgetauschten Nachrichten sämtliche Informationen enthalten, die notwendig sind, um sie zu verstehen. Der Server speichert keine Zusatzinformationen zwischen zwei Nachrichten wie beispielsweise in Form von Sessions. Die Zustandslosigkeit macht REST-Services sehr einfach skalierbar, da eingehende Anfragen im Rahmen von Lastverteilung unkompliziert auf verschiedene Server verteilt werden können.

• Unterschiedliche Repräsentationen der Ressourcen: Jede Ressource kann unterschiedliche Darstellungsformen besitzen. Je nachdem, was der Client anfordert, muss sie beispielsweise in verschiedenen Sprachen oder Formaten wie HTML, JSON oder XML ausgeliefert werden können.

• Hypermedia: Die Bereitstellung der Ressourcen geschieht über Hypermedia, z. B. in Form von „href“- und „src“-Attributen in HTML-Dokumenten oder für die jeweilige Schnittstelle definierten JSON- bzw. XML-Elementen. Somit navigiert der Client einer REST-API nach dem Prinzip „Hypermedia as the Engine of Application State (HATEOAS)“ ausschließlich über URLs, die der Server bereitstellt und benötigt kein zusätzliches Wissen über die Schnittstelle.

Diese strikten Vorgaben der REST-Architektur ermöglichen die Entwicklung gut strukturierter Dienste, die einfach zu integrieren sind und über ein einheitliches Protokoll (HTTP) kommunizieren. Dank der ressourcenorientierten Struktur entfällt bei der Konzipierung eines REST-Webservices außerdem die Suche nach anwendungsspezifischen Protokollen, die bei vergleichbaren Alternativen wie SOAP notwendig ist.

Um einen REST-Webservice zu realisieren, werden hauptsächlich HTTP und dessen verschlüsselte Version HTTPS verwendet. Das ist einerseits auf dessen enorme Verbreitung zurückzuführen, dank der es in so gut wie jeder Firewall offen ist; andererseits ist das zustandslose Hypertext Transfer Protocol auch vergleichsweise einfach aufgebaut, ohne dass spezielle Implementierungen vorausgesetzt werden. Zudem definiert der HTTP-Standard bereits ein ganzes Set an Befehlen, mit denen auf Ressourcen zugegriffen werden kann:

Die Befehlspalette kann durch die Implementierung weiterer Protokolle vergrößert werden. Typisch ist hier vor allem das WebDAV-Protokoll, das die Methoden COPY (Ressource kopieren), MOVE (Ressource verschieben), LOCK (Ressource sperren), UNLOCK (Ressource freigeben) und MKCOL (Verzeichnis erstellen) hinzufügt.

Das REST-Gerüst liefert hervorragende Mittel zur Konzipierung und Umsetzung von Webservices verschiedenster Art. Dank der Tatsache, dass nahezu alle Geräte das Hypertext Transfer Protocol unterstützen, können sowohl Desktop- als auch mobile Clients mühelos und ohne zusätzliche Implementierungen mit dem REST-Interface arbeiten. Das Ergebnis sind Webservices, die durch ein hohes Maß an

• Plattformunabhängigkeit,

• Skalierbarkeit,

• Performance,

• Interoperabilität

• und Flexibilität

überzeugen. Die Nutzung erfordert jedoch auch das entsprechende Know-how, wobei vor allem die Interaktion zwischen den einzelnen, zustandslosen Ressourcen sehr komplex und schwer zu bewerkstelligen ist. Wer bereits mit Alternativen wie dem Protokoll SOAP gearbeitet hat, wird durch die gänzlich anderen und ungewohnten Ansätze zum Umdenken gezwungen sein – besitzt am Ende aber einen Service, der sehr viel leichter in unerwarteten Kontexten nutzbar ist.