Representational State Transfer

aus Wikipedia, der freien Enzyklopädie
Wechseln zu: Navigation, Suche
QS-Informatik

Dieser Artikel wurde wegen inhaltlicher Mängel 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: Eine ganze Reihe von Aussagen sind schlicht falsch. S. Diskussionsbeitrag "Dieser Artikel ist eine einzige große Katastrophe"

Representational State Transfer (abgekürzt REST, seltener auch ReST) bezeichnet ein Programmierparadigma für Webanwendungen. REST ist eine Abstraktion der Struktur und des Verhaltens des World Wide Web. REST fordert, dass eine Web-Adresse (URI) genau einen Seiteninhalt repräsentiert, und dass ein Web-/REST-Server auf mehrfache Anfragen mit demselben URI auch mit demselben Webseiteninhalt antwortet.

Der Zweck von REST liegt schwerpunktmäßig auf der Maschine-Maschine-Kommunikation. REST stellt eine einfache Alternative zu ähnlichen Verfahren wie SOAP und WSDL und dem verwandten Verfahren RPC dar. Anders als bei vielen verwandten Architekturen kodiert REST keine Methodeninformation in den URI, da der URI Ort und Namen der Ressource angibt, nicht aber die Funktionalität, die der Web-Dienst zu der Ressource anbietet. Der Vorteil von REST liegt darin, dass im WWW bereits ein Großteil der für REST nötigen Infrastruktur (z. B. Web- und Application-Server, HTTP-fähige Clients, HTML- und XML-Parser, Sicherheitsmechanismen) vorhanden ist, und viele Web-Dienste per se REST-konform sind.

So ist ein Web-Dienst, der lediglich unveränderte Seiteninhalte nach dem Internetstandard HTTP anbietet, bereits REST-konform. Dynamisch erzeugte Seiten folgen diesem Paradigma jedoch oft nicht. So bieten beispielsweise Nachrichtenseiten sich ständig verändernde Informationen mit sowohl unterschiedlichem Format als auch Inhalt an, die schwer automatisch verarbeitet werden können. Bliebe das Format unverändert, so wäre eine wichtige REST-Eigenschaft erfüllt. Eine Webseite hingegen, auf der ständig die aktuelle Uhrzeit in immer demselben Format abrufbar ist, wäre REST-konform.

Geschichte[Bearbeiten]

Das REST-Protokoll entwickelte sich aus dem 1994 von Roy Fielding entworfenen HTTP Object Model. Fielding entwickelte seine Idee von einem einheitlichen Konzept über die Jahre weiter, bis er 2000 das REST-Modell im Rahmen seiner Dissertation veröffentlichte. Das Programmierparadigma der „RESTful Application“ wurde allerdings häufig falsch umgesetzt und findet eigentlich erst seit neuestem (Stand 2014) Anklang in der Welt des World Wide Web.

Prinzipien[Bearbeiten]

Es gibt vier Eigenschaften, die ein REST-Dienst haben muss, wobei nicht festgelegt ist, wie diese zu erreichen sind.

Adressierbarkeit[Bearbeiten]

Jeder REST-konforme Dienst hat eine eindeutige Adresse, den Uniform Resource Locator (URL). Diese „Straße und Hausnummer im Netz“ standardisiert den Zugriffsweg zum Angebot eines Webservices für eine Vielzahl von Anwendungen (Clients). Eine konsistente Adressierbarkeit erleichtert es außerdem, einen Webservice als Teil eines Mashups weiterzuverwenden. Zusätzlich zum URL, der den Dienst selbst adressiert, verwendet REST auch Uniform Resource Identifier (URI), um einzelne Ressourcen zu bezeichnen.

Unterschiedliche Repräsentationen[Bearbeiten]

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 einer Ressource ausliefern, z. B. in verschiedenen Sprachen oder Formaten (HTML, JSON oder XML) oder auch die Beschreibung oder Dokumentation des Dienstes.

Zustandslosigkeit[Bearbeiten]

Jede REST-Nachricht enthält alle Informationen, die für den Server bzw. Client notwendig sind, um die Nachricht zu verstehen. Weder der Server noch die Anwendung soll Zustandsinformationen zwischen zwei Nachrichten speichern. Man spricht daher von einem zustandslosen (englisch: stateless) Protokoll. Jede Anfrage eines Clients an den Server ist insofern in sich geschlossen, als 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 begünstigt die Skalierbarkeit eines Webservice. Beispielsweise können eingehende Anfragen im Zuge der Lastverteilung unkompliziert auf beliebige Maschinen verteilt werden: Da jede Anfrage 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. Weiterhin begünstigt wird die Ausfallsicherheit, weil die Zustandslosigkeit fordert, dass transaktionale Datenübertragung in einem einzigen Seitenaufruf erfolgt.

Operationen[Bearbeiten]

REST-konforme Dienste bieten verschiedene Operationen an, um Ressourcen bzw. Informationen auszuliefern oder zu verändern. Wird über HTTP zugegriffen, so gibt die verwendete HTTP-Methode, darunter GET, POST, PUT und DELETE, an, welche Operation des Dienstes gewünscht ist.

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, HEAD, 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.[1]

Umsetzung[Bearbeiten]

Für die Umsetzung des REST-Paradigmas wird ein zustandsloses Client-Server-Protokoll verwendet. Als Anwendungsschicht-Protokolle werden hauptsächlich HTTP und HTTPS eingesetzt. REST vereinheitlicht die Schnittstelle zwischen Systemen auf eine überschaubare und bezüglich des zu erwartenden Verhaltens standardisierte Menge von Aktionen. Welche Aktionen dies sind, ist in REST nicht festgelegt, aber alle Aktionen sind allgemein definiert, in der Regel durch die verwendeten Protokolle der Anwendungsschicht.

Während REST als Abstraktion des WWW keine spezielle Implementierung und kein spezielles Protokoll fordert, ist doch zu beobachten, dass fast ausschließlich HTTP verwendet wird, wodurch auch die Menge der Aktionen festgelegt ist.

REST-Clients, die HTTP verwenden, können folgende Befehle absetzen, um Ressourcen anzufordern oder zu verändern:

Befehl
(HTTP-Methode)
Beschreibung Anmerkungen
GET fordert die angegebene Ressource vom Server an. GET weist keine Nebeneffekte auf. Der Zustand am Server wird nicht verändert, weshalb GET als sicher bezeichnet wird. [n 1]
POST fügt eine neue (Sub-)Ressource unterhalb der angegebenen Ressource ein. Da die neue Ressource noch keinen URI besitzt, adressiert der 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. [n 2]
PUT die angegebene Ressource wird angelegt. Wenn die Ressource bereits existiert, wird sie geändert. [n 3]
PATCH ein Teil der angegebenen Ressource wird geändert. Hierbei sind Nebeneffekte erlaubt. [n 4]
DELETE löscht die angegebene Ressource. [n 3]
HEAD fordert Metadaten zu einer Ressource an. [n 4][n 1]
OPTIONS prüft, welche Methoden auf einer Ressource zur Verfügung stehen. [n 4][n 1]
CONNECT Dient dazu, die Anfrage durch einen TCP-Tunnel zu leiten. Wird meist eingesetzt, um eine HTTPS-Verbindung über einen HTTP-Proxy herzustellen. [n 4][n 1][n 5]
TRACE Gibt die Anfrage zurück, wie sie der Zielserver erhält. Dient etwa dazu, um Änderungen der Anfrage durch Proxyserver zu ermitteln. [n 4][n 1][n 5]
  1. a b c d e nullipotent. Ein Aufruf dieser Methoden führt zu keinen Nebeneffekten.
  2. nicht idempotent. Ein erneuter Aufruf erstellt für jeden Aufruf mit demselben URI ein neues Objekt, anstatt dasselbe Objekt zurückzugeben.
  3. a b idempotent. Der erste Aufruf dieser Methoden mit einem bestimmten URI führt zu Nebeneffekten. Ein erneuter Aufruf mit derselben URI führt zu keinen weiteren Nebeneffekten.
  4. a b c d e optional. Wird nicht für CRUD-Operationen benötigt.
  5. a b Eine Implementierung dieser Methoden wirkt sich ggf. auf die Sicherheit der Anwendung aus.

Sicherheit[Bearbeiten]

In der Theorie verlangt das Paradigma, dass alle Informationen, die eine Anwendung braucht, um den Seitenzustand wiederherzustellen, in der Anfrage enthalten sind. Dabei identifiziert der URI die Ressource, während im HTTP-Header Informationen wie Zugriffsart (GET, PUT), Rückgabeformat oder Authentifizierung enthalten sein können.

REST lässt sich für Webseiten und Webservices verwenden, die keine Authentifizierung erfordern oder diese auf anderem Wege (beispielsweise durch Prüfung der IP-Adresse, durch HTTP-Authentifizierung oder TLS/HTTPS-Zertifikatsprüfung) erreichen, wodurch bereits viele Anwendungsfälle abgedeckt werden können. Alternativ kann beispielsweise auch HMAC, OAuth oder OpenID verwendet werden.

Da REST – im Gegensatz zu SOAP mit WS-Security – selbst keine Verschlüsselungsmethoden definiert, wird bei sicherheitskritischen Nachrichten ein verschlüsseltes Transportprotokoll wie HTTPS verwendet.

HATEOAS[Bearbeiten]

Hypermedia as the Engine of Application State, kurz HATEOAS, ist ein Entwurfsprinzip von REST-Architekturen. Bei HATEOAS navigiert der Client einer REST-Schnittstelle ausschließlich über URLs, welche vom Server bereitgestellt werden.

Abhängig von der gewählten Repräsentation geschieht die Bereitstellung der URIs über Hypermedia, also z. B.

  • in Form von „href“- und „src“-Attributen bei HTML-Dokumenten bzw. HTML-Snippets, oder
  • in für die jeweilige Schnittstelle definierten und dokumentierten JSON- bzw. XML-Attributen/-Elementen.

Abstrakt betrachtet stellen HATEOAS-konforme REST-Services einen endlichen Automaten dar, dessen Zustandsveränderungen durch die Navigation mittels der bereitgestellten URIs erfolgt.

Durch HATEOAS ist eine lose Bindung gewährleistet und die Schnittstelle kann verändert werden. Im Gegensatz dazu kommuniziert ein SOAP-basierter Webservice über ein fixiertes Interface. Für eine Änderung des Services muss hier eine neue Schnittstelle bereitgestellt werden und in der Schnittstellenbeschreibung (ein WSDL-Dokument) definiert werden. Registrierungsdatenbanken oder ähnliche Infrastrukturen, die z. B. bei RFC erforderlich sind, werden bei HATEOAS nicht benötigt.

REST Maturity Model[Bearbeiten]

Das REST Maturity Model (REST-Reifegradmodell), kurz RMM, ist ein von Leonard Richardson entwickelter Maßstab, der angibt, wie strikt ein Service REST implementiert.

REST Maturity Model[2]
Level Eigenschaften
0
  • verwendet XML-RPC oder SOAP
  • der Service wird über einen einzelnen URI adressiert
  • verwendet eine einzelne HTTP-Methode (oft POST)
1
  • verwendet verschiedene URIs und Ressourcen
  • verwendet eine einzelne HTTP-Methode (oft POST)
2
  • verwendet verschiedene URIs und Ressourcen
  • verwendet mehrere HTTP-Methoden
3
  • basiert auf HATEOAS und verwendet daher Hypermedia für Navigation
  • verwendet verschiedene URIs und Ressourcen
  • verwendet mehrere HTTP-Methoden

Abgrenzung zu anderen Kommunikationsmechanismen[Bearbeiten]

Bei REST handelt es sich um ein Programmierparadigma, welches mit verschiedenen Mechanismen implementiert werden kann. Eine Neuerung ist dabei die Verwendung möglichst vieler HTTP-Methoden in Verbindung mit der auszuführenden Aktion. Im Gegensatz dazu wird zum Beispiel SOAP im Wesentlichen mit der POST-Methode verwendet. Der Unterschied liegt also mehr in der breiteren Verwendung von HTTP als Protokoll und URI als Identifizierungsmechanismus für konkrete Objekte. In der Vergangenheit wurden im Gegensatz dazu mit SOAP Schnittstellen RPC-basiert aufgebaut. Die engen Vorgaben von REST helfen, gut strukturierte Dienste zu bauen, und unterstützen die Verwendung von Clean URLs.

Siehe auch[Bearbeiten]

Literatur[Bearbeiten]

  •  Leonard Richardson, Sam Ruby: Web Services mit REST. O’Reilly Verlag, 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.
  •  Jamie Kurtz: ASP.NET MVC 4 and the Web API: Building a REST Service from Start to Finish. Apress, 30. Januar 2013, ISBN 978-1430249771.

Weblinks[Bearbeiten]

Java
.NET

Einzelnachweise[Bearbeiten]

  1. Fielding, et al.: 9 Method Definitions. In: Hypertext Transfer Protocol -- HTTP/1.1. 2004, abgerufen am 1. Juli 2010 (englisch).
  2. Martin Fowler: Richardson Maturity Model. 18. März 2010, abgerufen am 7. April 2013 (englisch, Erklärung des REST Maturity Models (RMM)).