Representational State Transfer
aus Wikipedia, der freien Enzyklopädie
Der Begriff Representational State Transfer bzw. das Akronym REST bezeichnen einen Softwarearchitekturstil für verteilte Hypermedia-Informationssysteme wie das World Wide Web. Während dessen Architektur durch den URI-Standard und das HTTP-Protokoll beschrieben werden kann, legt der REST-Architekturstil nahe, jede Ressource mit einer eigenen URI anzusprechen. Er gilt aktuell als eine der wesentlichen Richtlinien für die Nutzung von Web-Standards.
REST stammt aus der Dissertation von Roy Fielding aus dem Jahre 2000, in welcher der Erfolg des World Wide Webs auf bestimmte Eigenschaften der verwendeten Mechanismen und Protokolle (z. B. HTTP) zurückgeführt wird. Roy Fielding ist einer der Hauptautoren der Spezifikation des Hypertext-Transfer-Protokolls (HTTP).
Darüber hinaus findet derzeitig unter dem Banner von REST eine Rückbesinnung auf grundlegende Web-Technologien statt, die Implementierungen verteilter, webbasierter Systeme vereinfachen sollen.
Inhaltsverzeichnis |
[Bearbeiten] Prinzipien
[Bearbeiten] Adressierbarkeit
Der Web-Service macht die von ihm zur Verfügung gestellten Daten unter Verwendung von Ressourcen zugänglich, dabei ist jeder Ressource ein spezifischer URI zugeordnet. Die Adressierbarkeit durch einen URI stellt sicher, dass das Angebot eines Web Service auf einfache, standardisierte Art und Weise einer Vielzahl von Clients zur Verfügung steht. Eine ausgeprägte Adressierbarkeit erleichtert es, einen Web Service als Bestandteil eines Mashups zu verwenden.
[Bearbeiten] Zustandslosigkeit
REST-konforme Web Services differenzieren zwischen den Kategorien des Ressourcenzustands und des Anwendungszustands.
- Der Ressourcenzustand beinhaltet Informationen über eine Ressource, seine Verwaltung obliegt dem Server, der Client erhält Informationen über den Ressourcenzustand ausschließlich über die ihm zugestellten Repräsentationen einer Ressource.
- Der Anwendungszustand bezieht sich auf die Position eines Clients innerhalb der Anwendung, die Verwaltung des Anwendungszustandes obliegt dem Client. Im Gegensatz zu vielen RPC-artigen Architekturen hält ein REST-konformer Web Service zu keinem Zeitpunkt Informationen über den Anwendungszustand auf der Seite des Servers - z. B. in einer Session - vor.
REST setzt auf ein zustandsloses Client/Server-Protokoll. Dabei enthält jede HTTP-Botschaft alle Informationen, die notwendig sind, um die Nachricht zu verstehen. Deshalb muss weder der Server noch der Client Zustandsinformationen zwischen zwei Nachrichten speichern. Eine derartig strikte Trennung der Zuständigkeiten zwischen Client und Server führt dazu, dass ein REST-konformer Web Service als zustandslos (stateless) bezeichnet werden kann: Jede Anfrage eines Clients an den Server ist in dem Sinne in sich geschlossen, als dass sie sämtliche Informationen über den Anwendungszustand beinhaltet, die vom Server für die Verarbeitung der Anfrage benötigt werden. Dies gilt z. B. auch für Authentifizierungsinformationen; statt "login via cookie" wird in jeder URI z.B. ein Password-hashcode übertragen.
Zustandslosigkeit in der hier beschriebenen Form wirkt sich begünstigend auf die Skalierbarkeit eines Web Service aus. Beispielsweise können eingehende Anfragen im Zuge des Load Balancing unkompliziert auf beliebige Maschinen verteilt werden: da jeder Request in sich geschlossen ist und Anwendungsinformationen somit ausschließlich auf der Seite des Clients vorgehalten werden, ist auf der Seite des Servers kein Session Handling erforderlich. In der Praxis nutzen jedoch viele HTTP-basierte Anwendungen Cookies und andere Techniken, um Zustandsinformationen zu behalten.
[Bearbeiten] Wohldefinierte Operationen
REST sieht eine Menge wohldefinierter Operationen vor, die auf alle Informationen (Ressourcen genannt) angewendet werden können: HTTP selbst definiert eine Reihe von Operationen, darunter GET, POST, PUT und DELETE.
[Bearbeiten] Verwendung von Hypermedia
Sowohl für Anwendungsinformationen als auch für Zustandsveränderungen werden Hypermedia benutzt: Repräsentationen in einem REST-System sind typischerweise im HTML- oder XML-Format, welche sowohl Informationen als auch Links zu anderen Ressourcen enthalten. Deshalb ist oftmals möglich, von einer Ressource zu einer anderen zu navigieren, indem man einfach Verknüpfungen folgt, ohne dass dafür Registrierungsdatenbanken oder ähnliche Infrastrukturen erforderlich sind. Diese Verknüpfung von Ressourcen innerhalb einer REST-Architektur wird auch als Verbindungshaftigkeit bezeichnet.
[Bearbeiten] Umsetzung
REST vereinheitlicht die Schnittstelle zwischen Systemen auf eine überschaubare und - bezüglich des zu erwartenden Verhaltens - standardisierte Menge von Aktionen (=Verben). Welche Aktionen dies sind, ist in REST nicht festgelegt, aber alle Aktionen sind allgemein definiert.
Für die Umsetzung des REST-Architekturstils werden meist Internet-Technologien verwendet. Als Transportprotokoll wird meistens das HTTP verwendet.
- Mit GET fordert der Client Daten vom Server an:
- Mit POST werden neue Daten/Ressourcen auf dem Server abgelegt.
- Mit PUT werden vorhandene Daten aktualisiert oder untergeordnete Ressourcen ergänzt.
- Mit DELETE löscht der Client Daten auf dem Server.
- Mit HEAD fordert der Client Metadaten zu einer Ressource vom Server an.
- Mit OPTIONS prüft der Client, welche Methoden auf einer Ressource zur Verfügung stehen
Im Gegensatz zu vielen RPC-Architekturen kodiert REST keine Methodeninformation im URI, da der URI die Ressource identifiziert (wie der Name es auch sagt), und nicht das, was mit ihr getan werden soll
[Bearbeiten] Siehe auch
[Bearbeiten] Weblinks
- Architectural Styles and the Design of Network-based Software Architectures - Dissertation von Roy Fielding, in der REST beschrieben wird
- REST Wiki (englisch)
- Restlet - Leichtgewichtiges REST Framework für Java
- JSR 311 JAX-RS: The Java API for RESTful Web Services
- The quick pitch - Pragmatische Empfehlungen für die Anwendung von REST
[Bearbeiten] Literatur
Richardson, L. & Ruby, S. (2007): Web Services mit REST Köln (u.a.): O'Reilly.
