home  |  suche  |  kontakt/johner  |  institut 
studierende  |  tech-docs  |  mindmailer 

REST - Representational State Transfer

 Ob REST in der Rubrik Webservices überhaupt richtig aufgehoben ist, kann diskutiert werden. Denn die Definition eines Webservices als eine Softwarekomponente, deren Schnittstelle über XML-Artefakte beschrieben sind, trifft nicht zu. Die REST Schnittstellen sind nicht mittels XML spezifiziert.

Doch der Reihe nach: REST steht für Representational State Transfer. Wieso werden wir später sehen. REST ist kein Produkt, nicht einmal ein Standard, nutzt aber intensiv Web-Standards wie HTML, HTTP und XML.

Bei einer mit SOAP realisierten Webanwendung sind die Methoden und deren Übergabe- und Rückgabeparameter in der WSDL (siehe hierzu die Einführung in Webservices mit SOAP). Der Webservice-Client kommuniziert mit der URL, die im WSDL-Dokument definiert ist. Wohlgemerkt: mit einer URL. Bei dieser URL finden sich dann beliebig viele Methoden. Ebenfalls im WSDL-Dokument spezifiziert. Die Requests werden üblicherweise über HTTP-Post zum Server gesendet.

Bei REST hingegen gibt es viele URLs. Beispielsweise könnte es bei einer Anwendungen zur Verwaltung eines Fuhrparks folgende URLs geben:

  • /fahrzeuge
  • /fahrzeuge/<fahrzeug>
  • /fahrzeuge/<fahrzeug>/fahrten
  • /fahrzeuge/<fahrzeug>/fahrten/<fahrt>

Entsprechend würden

  • alle Fahrzeuge,
  • ein bestimmtes mit <fahrzeug> identifierbares Fahrzeug,
  • alles Fahrten dieses Fahrzeugs oder
  • eine mit <fahrt> bestimmte Fahrt dieses Fahrzeugs angezeigt werden.

Die spitzen Klammern stehen stellvertretend für einen eindeutigen Kennzeichner, bespielsweise die Fahrzeugnummer.

Was diese URLs bedeuten ist zwar naheliegend aber nicht (via XML) definiert. Es ist dem Entwickler überlassen die Pfade zu bestimmen und zu dokumentieren.

Vergleich der Client-Server-Kommunikation bei REST (oben) und bei SOAP (unten). Zum Vergrößern klicken.

Das WWW stellt in gewisser Weise die größte REST-Anwendung dar, wenn gleich sich die Aufrufe zu 99% auf GET-Requests beschränken. Die identische Navigierbarkeit verdeutlicht auch die folgende Abbildung:

Mit den oben gezeigten Pfaden ließen sich Ressourcen anzeigen. Nun gibt es neben den lesenden Zugriffen noch weitere. Insgesamt sind das die klassischen CRUD-Operationen

  • Create: Anlegen einer Ressource
  • Read: Anzeigen einer Ressource (wie oben gezeigt)
  • Update: Ändern einer Ressource
  • Delete: Löschen einer Ressource.

Nun könnte man über die URL ausdrücken, dass eine Ressource auch geändert, gelöscht oder neu angelegt werden soll. Die Information darüber, was getan werden soll, verpackt man aber üblicherweise in den HTTP Methoden:

  • GET zum Anzeigen (wie oben gezeigt)
  • POST zum Anlegen einer Ressource
  • PUT zum Ändern einer Ressource und
  • DELETE zum Löschen einer Ressource

Wohlgemerkt: die Auswahl welche HTTP-Methode für welche CRUD-Operation verwendet wird, ist nicht festgelegt, sondern die Entscheidung des Entwicklers.

Damit ließe sich unsere Fuhrpark-Anwendung beispielsweise wie folgt steuern:

  • Anzeigen eines Fahrzeugs: GET: /fahrzeuge/   oder  /fahrzeuge/KN-AZ1
  • Ändern eines Fahrzeugs: PUT: /fahrzeuge/KN-AZ-1 kennzeichen=KN-B123&fahrzeugtyp=Bentley&ps=240
  • Anlegen eines Fahrzeugs: POST: /fahrzeuge/KN-AZ-1 kennzeichen=KN-B123&fahrzeugtyp=Bentley&ps=240
  • Löschen eines Fahrzeugs: DELETE: /fahrzeuge/KN-AZ1

Ebenso wie HTTP ist auch die REST Kommunikation stateless. Es besteht auch keine Veranlassung, diese Tatsache durch das Setzen von Cookies oder anderen zustandbehafteten Informationen zu umgehen.

Representation und Ressourcen

Bei den Resourcen handelt es sich unserem obigen Fall einmal um die Menge aller Fahrzeuge, bei anderem Mal um ein einzelnes Fahrzeug, mal um die Menge aller Fahrten oder nur um eine einzige. Wie diese Ressourcen dargestellt werden, beispielweise als HTML-Tabelle, als XML-Dokument, als Text oder PDF-Dokument nennt man die Repräsentation. Und der Zustand der Repräsentation kann sich ändern. Nämlich beim Anlegen, Ändern oder Löschen von Ressourcen. Und dies gibt dem Architekturstil seinen Namen: Representational State Transfer - REST.

Sie werden es schon ahnen: Auch die Auswahl der Repräsentationsform bleibt dem Entwickler überlassen und ist nicht wie bei SOAP in einem WSDL-Dokument beschrieben.

Vergleich REST und SOAP

Aspekt Rest SOAP
Sicherheit Einfach über HTTP Adressen und Befehle (kein Applikationswissen notwendig,
Adressierung Jede Ressource über eigene URI. Ressourcen können untereinander verlinken. Auch externe Ressourcen lassen sich einfach einbinden Über Dispatcher, Client kennt nur eine Adresse
Skalierung Bei GET kann Server Ressourcen gut cachen (wie Webserver Seiten cached) Immer Post, kein Caching
Schnittstelle Nur über URI (nicht in Request) spezifiziert. Gibt nur HTTP Methoden Genaue Methodennamen, Rück- und Übergabedatentypen
Fokus Ressource Service
Tools Restlet Axis
Fazit Leichtgewichtig, zumindest GET leicht zu testen, einfach zu verstehen Konsistente Dokumentation und Code-Generierung