Wikipedia

Representational State Transfer

Programmierparadigma für verteilte Systeme, insbesondere für Webservices
Dies ist eine alte Version dieser Seite, zuletzt bearbeitet am 8. Juli 2014 um 23:21 Uhr durch Reaper35 (Diskussion | Beiträge) (→Geschichte: Typo/Grammatik). Sie kann sich erheblich von der aktuellen Version unterscheiden.
Eine gesichtete Version dieser Seite, die am 8. Juli 2014 freigegeben wurde, basiert auf dieser Version.

Representational State Transfer (mit dem Akronym REST, seltener auch 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 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 (Permalinks) bereits vorsieht; ein Ziel, das für dynamisch erzeugte Seiten mitunter jedoch zusätzlichen Aufwand erfordert.

QS-Informatik
Beteilige dich an der Diskussion!
 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"

Geschichte

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-Model im Rahmen seiner Dissertation veröffentlichte. Der Architekturstil der RestFul Application wurde allerdings häufig falsch oder gar nicht umgesetzt und findet erst seit neuestem (Stand 2014) wirklich Anklang in der Welt des World Wide Web. Vor REST wurde häufig SOAP oder WSDL verwendet, die zwar ähnlich funktionieren, aber auf dem Prinzip der Transportunabhängigkeit aufbauen und HTTP nur als weiteres Mittel zum Transport von Daten verwenden.

Prinzipien

Es gibt fünf 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 Locator (URL). Diese „Straße und Hausnummer im Netz“ 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.

Zusätzlich zum URL, der den Service selbst adressiert, verwendet REST auch Uniform Resource Identifier (URI), um einzelne Ressourcen zu bezeichnen.

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, wobei im Normalfall HTTP oder HTTPS eingesetzt wird. Jede REST-Nachricht enthält dabei 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. Eine derartig strikte Trennung der Zuständigkeiten zwischen Client und Server führt dazu, dass ein REST-konformer Webservice als zustandslos (englisch: 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, 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]

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

Befehl
(HTTP-Verb)		 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 keine URI besitzt, adressiert den 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. Wenn der Client versucht, eine Ressource zu löschen, die nicht existiert bzw. bereits gelöscht wurde, erhält der Client – sofern die REST-Schnittstelle korrekt implementiert wurde – keine Fehlermeldung (siehe auch: HTTP-Statuscodes). Abhängig von der Implementierung wird eine Ressource meist – entgegen der HTTP-Spezifikation – nicht physisch gelöscht, sondern nur als gelöscht gekennzeichnet und somit versteckt und deaktiviert. [n 3]
HEAD fordert Metadaten zu einer Ressource vom Server 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 derselben URI ein neues Objekt, anstatt dasselbe Objekt zurückzugeben.
  3. ↑ a b idempotent. Der erste Aufruf dieser Methoden mit einer 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.

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

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.

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

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

REST Maturity Model

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

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

Abgrenzung zu anderen Kommunikationsmechanismen

Bei REST handelt es sich um ein Programmierparadigma, welches mit verschiedenen Mechanismen implementiert werden kann. Eine Neuerung ist dabei die Verwendung von möglichst vielen HTTP-Verben in Verbindung mit der auszuführenden Aktion. Im Gegensatz dazu wird zum Beispiel SOAP im Wesentlichen mit dem Verb POST 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 wurde im Gegensatz dazu mit SOAP ein RPC-basierter Aufbau der Schnittstellen durchgeführt. Die starken Vorgaben von REST helfen gut strukturierte Dienste zu bauen und unterstützen die Verwendung von Clean URLs.

Siehe auch

Literatur

Java
.NET

Einzelnachweise

  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)).
Webserver-Schnittstellen
Protokolle

CGI | SCGI | FastCGI | AJP

APIs

C NSAPI | C ASAPI | C ISAPI | Jakarta Servlet | ASP.NET | Python WSGI | Ruby Rack | JavaScript JSGI | PSGI | Lua WSAPI 

Apache-Module

mod_jk | mod_lisp | mod_parrot | mod_perl | mod_php | mod_python | mod_wsgi | mod_ruby | Phusion Passenger 

Web APIs

WSDL | XML-RPC | SOAP | REST 

Abgerufen von „https://de.wikipedia.org/w/index.php?title=Representational_State_Transfer&oldid=131977062“