23
October 2012

REST als Modewort?

Was ist eigentlich ein «REST» Web Service? Bei dem Versuch diese Frage zu klären, stellte der Autor dieses Artikels fest, dass sich viele prominente Anbieter von sog. «REST» Web Services gar nicht an die eigentliche Architektur von «REST» halten.

«REST» steht für «Representational State Transfer». Die Architektur für RESTful Web Services wurde im Jahr 2000 durch den amerikanischen Computerwissenschaftler Roy Fielding im Rahmen seiner Dissertation entwickelt.

Ein REST Web Service muss sich gemäss dieser Spezifikation an strikte Vorgaben halten. So werden beispielsweise für die verwalteten Ressourcen eindeutige «Uniform Resource Identifier» (kurz URI) Adressen verlangt.

Zwei Beispiel:

Adresse aller Ressourcen vom Typ «User»:

http://mywebsite.ch/api/users

Adresse aller Posts (z.B. Einträge im Forum) vom User «rogerguillet»:

http://mywebsite.ch/api/users/rogerguillet/posts

CRUD - create, read, update, delete

Ein REST Web Service baut auf dem Hypertext Transfer Protokoll (HTTP) auf und nutzt ganz bewusst dessen Architektur aus. Die HTTP-Methoden wie z.B. GET, POST, PUT und DELETE werden verwendet, um die Serverseitige Verarbeitung zu steuern. Während beispielsweise POST für das Einfügen von neuen Datensätzen verwendet wird, können mittels GET Daten abgefragt werden.

Auch die Verwendung des Internet Media Types (z.B. application/json) ist in der REST Architektur vorgesehen, um die übermittelten Daten (Content-Type), sowie die erwartete Antwort (accept) zu kennzeichnen. Gewisse REST Implementationen gehen gar soweit, im Media Type die verwendete Version der Web Service Ressource zu kennzeichnen.

Beispiel eines REST HTTP-Headers:

POST http://localhost:8080/myressource HTTP/1.1
User-Agent: Mozilla/5.0
Host: localhost:8080
Content-Type: application/myressource.v2.json
Accept: application/json

Der Media Type application/myressource.v2.json kennzeichnet mit «v2» die übergebene Version der Ressource «myressource» im JSON Format.

REST setzt Hypermedia voraus

Soweit so gut. Viele Web Services, welche die oben beschriebene Form für die Datenübermittlung verwenden, werden als REST Services bezeichnet. Die grundlegende Idee, Ressourcen über einheitliche, sprechende URI Adressen zugänglich zu machen und HTTP als Träger für Service-Informationen zu nutzen, ist natürlich sehr schlau. Doch Roy Fielding geht mit der Spezifikation von REST noch weiter: Damit sich ein Web Service als RESTful Web Service bezeichnen darf, sagt Fielding, muss dieser Hypermedia Links verwenden.

Hypermedia bedeutet, dass zu jeder Ressource alle wichtigen service-internen Links auf andere Repräsentationen, oder die für die aktuelle Ressource verfügbaren Prozessschritte, durch den Webservice zur Verfügung gestellt werden müssen. Der Konsument (Client) eines Web Service oder einer API sollte dank Hypermedia durch alle Ressourcen navigieren können, auch wenn ihm zu Beginn nur die Haupt-URI des Web Service bekannt ist.

Ein Beispiel: Wir haben einen Service, welcher eine Liste von Forum-Beiträgen zurückgibt. Nun könnte beispielsweise eine Repräsentation eines einzelnen Beitrags einen Hypermedia Link auf den vorhergehenden und den darauffolgenden Beitrag enthalten. Der Client, welcher den Web Service konsumiert, könnte nun also zwischen Forumbeiträgen hin und her navigieren, ohne dass er selbst eine Logik für das Vor- und Zurückspringen zwischen den Beiträgen implementieren muss.

Der Webservice gibt ihm also die Logik vor. Man könnte also sagen, Clients eines REST Web Service im eigentlichen Sinne sind grundsätzlich «dumme» Clients, denn sie folgen der ihnen durch den Service vorgegebenen Prozess-Logik. Durch den «Code-On-Demand Constraint», wird diese Idee weiter verdeutlicht. Dieser Constraint besagt nämlich, dass ein REST Web Service seinen Clients bei Bedarf Programm-Code nachreichen darf, welcher anschliessen Clientseitig ausgeführt wird.

REST allows client functionality to be extended by downloading and executing code in the form of applets or scripts.
http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_1_7  

Gemäss Roy Fielding darf es in einer REST Architektur keine fixen Typen geben. Das bedeutet, die Struktur der Daten kann sich jederzeit ändern, worauf der Client flexibel reagieren muss. Der Client müsste folglich alle Daten verarbeiten können, egal ob der Service E-Banking Daten oder Informationen aus einer Enzyklopädie übermittelt.

Folglich wollte Fielding mit der REST Architektur per Definition nicht eine Alternative zu bestehenden, typ-basierten Webservices wie z.B. SOAP, XML-RPC oder JSON-RPC schaffen, sondern vielmehr eine Datenstruktur, mit dynamischen Verweisen (Links) zwischen den Repräsentationen untereinander, kreieren. REST ist daher eher mit HTML, als mit SOAP vergleichbar.

Think of it in terms of the Web. How many Web browsers are aware of the distinction between an online-banking resource and a Wiki resource? None of them. They don’t need to be aware of the resource types. What they need to be aware of is the potential state transitions — the links and forms — and what semantics/actions are implied by traversing those links.
http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven#comment-720

REST als Modewort

Wie der frustriete Blog-Eintrag des REST-Architekten Roy Fielding mit dem Titel «REST APIs must be hypertext-driven» beweist, wird der Begriff «REST» häufig missverstanden, um nicht zu sagen: Missbraucht. Viele Web Services, die als RESTful bezeichnet werden, erfüllen wesentliche Bestandteile der REST-Architektur nicht, oder nur teilweise.

Beispiel – Flickr «REST» Service:

Zu finden unter: http://www.flickr.com/services/api/request.rest.html

Bereits im 1. Beispiel für einen Aufruf des Flickr Service findet man einen wesentlichen Fehler, der absolut dagegen spricht, dass es sich hier um einen «echten» REST Web Service handelt:

http://api.flickr.com/services/rest/?method=flickr.test.echo&name=value

Hier wird ganz klar eine entfernte Methode aufgerufen. Damit entspricht dieses Beispiel dem Aufruf eines «Remote Procedure Call» (Kurz: RPC) Web Services.

Beispiel 2 – Microsoft «Live Connect REST reference»

Zu finden unter: http://msdn.microsoft.com/en-us/hh243648#contact

Der Service entspricht zwar, mit dem Ansatz, wie auf die Repräsentationen von Ressourcen zugegriffen wird, eher der REST Architektur, allerdings fehlen hier die Hypermedia Links auf abhängige Ressourcen.

Diese beiden Beispiele zeigen, dass auch grosse Software Unternehmen die REST Architektur in ihrer Interpretation sehr frei auslegen.

Positiv zu sehen ist jedoch, dass die meisten Web Services, welche als «REST Web Service» bezeichnet werden, gute Ideen der REST Architektur übernommen haben. Hier ein paar Beispiele:

  • HTTP Methoden wie GET, POST, PUT oder DELETE für die Kennzeichnung der erwarteten, serverseitigen Aktion.
  • Feste und lesbare URI für den Zugriff auf Ressourcen.
  • Nutzung des Media Types für die Kennzeichnung der übermittelten Daten.
  • Zustandslosigkeit der Anfrage an den Server (keine Sessions).
Platzhalter