Benutzer:Thomas aus Mainz/Open Services for Lifecycle Collaboration

Der Begriff Open Services for Lifecycle Collaboration (Abgekürzt OSLC) bezeichnet eine technische Schnittstelle zum Datenaustausch zwischen Anwendungsentwicklungswerkzeugen.

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.

Der Begriff wird auch im weiteren Sinne verwendet, um grundsätzlich einfache Schnittstellen zu kennzeichnen, die Daten über HTTP übertragen, ohne etwa eine zusätzliche Transportschicht wie SOAP oder Sitzungsverwaltung über Cookies einzusetzen.

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.

Jede Ressource, die ein REST-konformer Webservice zur Verfügung stellt, hat eine spezifische Adresse, den Uniform Resource Identifier (URI). Die Adressierbarkeit durch einen URI stellt sicher, dass das Angebot eines Webservices auf einfache, standardisierte Art und Weise einer Vielzahl von Clients zur Verfügung steht. Eine konsistente Adressierbarkeit erleichtert es, einen Webservice als Teil eines Mashups zu verwenden.

Die unter einer Adresse zugänglichen Ressourcen können unterschiedliche Repräsentationen haben. Ein REST-konformer Webservice kann z.B. je nach dem, was der Client anfordert, eine HTML- oder XML-Repräsentation ausliefern. Hierdurch könnte der Standard-Webbrowser zum Navigieren durch den Webservice verwendet werden und/oder die Beschreibung und Dokumentation des Services über die gleiche Adresse verfügbar gemacht werden.

REST-konforme Webservices 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 Webservice zu keinem Zeitpunkt Informationen über den Anwendungszustand auf der Seite des Servers – z. B. in einer Sitzung – 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 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.

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.

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

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.

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

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

• Leonard Richardson, Sam Ruby: Web Services mit REST. O'Reilly, 2007, ISBN 978-3-89721-727-0. 
• Stefan Tilkov: REST und HTTP. Einsatz der Architektur des Web für Integrationsszenarien. dpunkt Verlag, 2009, ISBN 978-3-89864-583-6. 

1. ↑ Fielding, et al.: 9 Method Definitions. In: Hypertext Transfer Protocol -- HTTP/1.1. 2004, abgerufen am 1. Juli 2010 (englisch). 

• 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)

Kategorie:Softwarearchitektur Kategorie:Webservice