Representational State Transfer

Dieser Artikel wurde aufgrund von inhaltlichen Mängeln auf der Qualitätssicherungsseite der Redaktion Informatik eingetragen. Dies geschieht, um die Qualität der Artikel aus dem Themengebiet Informatik auf ein akzeptables Niveau zu bringen. Hilf mit, die inhaltlichen Mängel dieses Artikels zu beseitigen und beteilige dich an der Diskussion! (+)
Begründung: Allgemeinverständlichkeit nicht gegeben. Siehe Diskussion:Representational_State_Transfer -- Nolispanmo Disk. Hilfe? 13:23, 16. Sep. 2010 (CEST)

Representational State Transfer (mit dem Akronym REST) bezeichnet ein Programmierparadigma für Webanwendungen. Es gibt keine explizite Norm, daher gehen die Vorstellungen, was REST ist, auseinander. Im Grunde bezeichnet REST die Idee, dass eine Internetadresse (URL) genau einen Seiteninhalt als Ergebnis einer serverseitigen Aktion (etwa das Anzeigen einer Trefferliste nach einer Suche) darstellt, wie es der Internetstandard HTTP für statische Inhalte bereits vorsieht, ein Ziel, das für dynamisch erzeugte Seiten mitunter jedoch zusätzlichen Aufwand erfordert. (Bei statischen Inhalten spricht man bei dieser Funktionalität von einem Permalink.)

In der Praxis ist in der Regel gewollt, dass sich URLs aus dem Webbrowser als Lesezeichen ablegen und zu einem beliebigen späteren Zeitpunkt wieder aufrufen lassen können. Sie sollen auch an Dritte weitergegeben werden und von diesen aufgerufen werden können und dieselbe Aktion auslösen (etwa eine Suche durchführen). Auch eine gewisse Form der Bedienbarkeit der Anwendung ist in der Regel gewünscht^[1].

Geschichte

REST stammt aus der Dissertation von Roy Fielding aus dem Jahre 2000, in der er den Erfolg des World Wide Webs auf bestimmte Eigenschaften der verwendeten Mechanismen und Protokolle (z. B. HTTP) zurückführt. Fielding war zuvor auch an der Spezifikation des Hypertext-Transfer-Protokolls (HTTP) beteiligt.

REST gilt in seiner Konsequenz als eine wichtige Richtlinie für die Nutzung von Web-Standards, in Abgrenzung zu vielen historisch gewachsenen Verfahren. Daraus folgt teils eine Rückbesinnung auf grundlegende Web-Technologien, die die Implementierung verteilter webbasierter Systeme vereinfachen soll.

Prinzipien

Es gibt sechs Eigenschaften, die ein REST-Dienst haben muss, wobei es den einzelnen Diensten überlassen ist, wie es implementiert wird.

Adressierbarkeit

Jeder Dienst, den ein REST-konformer Server zur Verfügung stellt, hat eine eindeutige Adresse, den Uniform Resource Identifier (URI). Diese "Straße und Hausnummer im Netz" durch einen URI stellt sicher, dass das Angebot eines Webservices auf einfache, standardisierte Art und Weise einer Vielzahl von Anwendungen (Clients) zur Verfügung steht. Eine konsistente Adressierbarkeit erleichtert es außerdem, einen Webservice als Teil eines Mashups weiterzuverwenden.

Unterschiedliche Repräsentationen

Die unter einer Adresse zugänglichen Dienste können unterschiedliche Darstellungsformen (Repräsentationen) haben. Ein REST-konformer Server kann je nachdem, was die Anwendung anfordert, verschiedene Repräsentationen ausliefern (z. B. HTML, JSON oder XML). Damit kann der Standard-Webbrowser über die gleiche URI-Adresse sowohl den Dienst, als auch die Beschreibung oder Dokumentation abrufen. Es wird nicht der interne Datenbankeintrag ausgeliefert, sondern das je nach Anfrage evtl. in eine bestimmte Kodierung oder Sprachversion übertragene Dokument.

Zustandslosigkeit

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 die Anwendung Zustandsinformationen zwischen zwei Nachrichten speichern. Eine derartig strikte Trennung der Zuständigkeiten zwischen Client und Server führt dazu, dass ein REST-konformer Webservice 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.

Zustandslosigkeit in der hier beschriebenen Form wirkt sich begünstigend auf die Skalierbarkeit eines Webservices aus. Beispielsweise können eingehende Anfragen im Zuge der Lastverteilung 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 keine Sitzungsverwaltung erforderlich. In der Praxis nutzen jedoch viele HTTP-basierte Anwendungen Cookies und andere Techniken, um Zustandsinformationen zu behalten.

Operationen

REST-konforme Dienste müssen einige Operationen vorsehen, die auf alle Dienste (Ressourcen genannt) angewendet werden können. HTTP, zum Beispiel, hat eine klar definierte Menge von Operationen, darunter GET, POST, PUT und DELETE.

HTTP schreibt vor, dass GET „sicher“ (englisch safe) sein muss, was bedeutet, dass diese Methode nur Informationen beschafft und keine sonstigen Effekte verursacht. Die Methoden GET, PUT und DELETE müssen laut HTTP-Spezifikation idempotent sein, was in diesem Zusammenhang bedeutet, dass das mehrfache Absenden der gleichen Anforderung sich nicht anders auswirkt als ein einzelner Aufruf.^[2]

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 es 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.

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 Anwendungsschicht-Protokoll dient hauptsächlich HTTP.

Der Client kann folgende Befehle absetzen

GET

fordert die angegebene Ressource vom Server an.

POST

fügt eine neue (Sub-)Ressource unterhalb der angegebenen Ressource ein. Da die neue Ressource noch keine URI besitzt, adressiert die URI die übergeordnete Ressource. Als Ergebnis wird der neue Ressourcenlink dem Client zurückgegeben. POST kann im weiteren Sinne auch dazu verwendet werden Operationen abzubilden, die von keiner anderen Methode abgedeckt werden.

PUT

die angegebene Ressource wird angelegt oder dazu geändert.

DELETE

löscht die angegebene Ressource.

HEAD

fordert Metadaten zu einer Ressource vom Server an.

OPTIONS

prüft, welche Methoden auf einer Ressource zur Verfügung stehen.

Im Gegensatz zu vielen RPC-Architekturen kodiert REST keine Methodeninformation in den URI, da der URI Ort und Namen der Ressource angibt, nicht aber die Funktionalität, die die Ressource anbietet. Es wird versucht, die Funktionalität hauptsächlich über die HTTP-Verben abzubilden.

Sicherheit

In der Theorie verlangt das Paradigma, dass alle Informationen, die eine Anwendung braucht, um den Seitenzustand wieder herzustellen, in der Anfrage enthalten sind. Dabei identifiziert die URI die Ressource während im HTTP-Header Informationen wie Zugriffsart (GET, PUT), Rückgabeformat oder Authentifizierung enthalten sein können. In seiner Reinform lässt sich REST für Webseiten und Webservices verwenden, die keine Authentifizierung erfordern oder diese auf anderem Wege (beispielsweise durch Prüfung der IP-Adresse) oder über HTTP-Authentifizierung erreichen, wodurch bereits viele Anwendungsfälle abgedeckt werden können. Alternativ kann beispielsweise auch HMAC, OAuth oder OpenID verwendet werden.

Abgrenzung zu anderen Kommunikationsmechanismen

REST versucht das Potenzial des World Wide Web vollständig auszunutzen. Die Festlegung einer bestimmten Kommunikationstechnologie kann auch zur Hürde für eine Kommunikation werden. Auch SOAP über HTTP bringt seine eigene Komplexität mit. HTTP als Protokoll und URI als Identifizierungsmechanismus bietet sich aufgrund seiner großen Verbreitung und allgemeinen Akzeptanz an.

Siehe auch

• URI
• Architektur (Informatik)
• Java API for RESTful Web Services (JAX-RS)
• Webservice – „klassische“ SOAP-basierte Webservices
• Web Application Description Language – Beschreibungssprache für REST-basierte Dienste

Literatur

• Leonard Richardson, Sam Ruby: Web Services mit REST. O'Reilly, 1. Oktober 2007, ISBN 978-3897217270.
• Stefan Tilkov: REST und HTTP. Einsatz der Architektur des Web für Integrationsszenarien. dpunkt Verlag, 27. Juli 2009, ISBN 978-3898645836.

Einzelnachweise

1. ↑ http://www.useit.com/alertbox/990321.html
2. ↑ Fielding, et al.: 9 Method Definitions. In: Hypertext Transfer Protocol -- HTTP/1.1. 2004, abgerufen am 1. Juli 2010 (englisch). 

Weblinks

• Architectural Styles and the Design of Network-based Software Architectures – Dissertation von Roy Fielding, in der REST beschrieben wird
• Jersey, Restlet und Jboss RESTEasy – REST Frameworks 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 (englisch)
• REST Web Services – Einführung in RESTful Web Services (deutsch)
• RESTful Web services: The basics – Basisprinzipien von REST (englisch)
• REST – Der bessere Web Service? Grundlagen der REST-Architektur
• RESTful HTTP in practice – REST in der Praxis (englisch)