REpresentational State Transfer – REST

Bei Groupware-Systemen besteht oft die Anforderung an hohe Verteilbarkeit und lose Kopplung, damit sich das System an sich ändernde Prozesse dynamisch anpassen kann. Weiterhin spielt Skalierbarkeit, Wiederverwendbarkeit und robuste Implementierung von Komponenten eine entscheidende Rolle, wie auch die Übertragung über das Internet. Hier soll dargestellt werden, wie der REST Architekturstil diesen Anforderungen Rechnung trägt.

Bei verteilten Anwendungen können Nutzer und genutzte Dienste über die ganze Welt verteilt sein. Das WWW (World Wide Web) ist eine verteilte Anwendung, die Dokumente auf der ganzen Welt miteinander verknüpft. Der Zugriff auf Dokumente erfolgt über Links innerhalb anderer Dokumente. Dokumente können unterschiedliche Repräsentationsformate haben und zur Übertragung werden verschiedene Protokolle, die meist auf Standards beruhen, herangezogen. Ziel des WWW ist, die intuitive Gestaltung der Interaktion zwischen Mensch und Hypertext-Dokumenten [Bern96].

Das WWW ist weiterhin eine typische Client-Server-Architektur. Der Server stellt Dokumente als Ressource oder Dienste zur Verfügung, die über einen Universal Resource Identifier (URI) eindeutig adressiert werden. Die Kommunikation erfolgt über Nachrichten (Request-/Response-Paradigma) mit dem Hypertext Transfer Protokoll (HTTP) als Übertragungsformat.

Kernprinzipien für RESTful HTTP nach Tilkov

REpresentional State Transfer (REST) ist ein Architekturstil, der von Roy Fielding in seiner Dissertation entscheidend geprägt wurde [Fie00]. REST ist ein Architekturstil für verteilte Hypermedia-Systeme und basiert auf HTTP. REST bietet eine Reihe von architektonischen Prinzipien, die als Ganzes angewandt die Skalierbarkeit der Komponenten, Allgemeingültigkeit von Schnittstellen, unabhängige Verteilbarkeit (Deployment) von Komponenten erzielen. Dadurch werden Wartezeiten bei Interaktionen verringert, die Sicherheit erhöht und Legacy-Systeme gekapselt [Fie00, S. 3].

Nach Tilkov [Til11, S. 10] muss genau genommen zwischen dem abstrakten Architekturstil REST, der konkreten, weitgehend REST-konformen Implementierung HTTP und einzelnen Webanwendungen und Diensten unterschieden werden, die mehr oder weniger konform zu den REST-Prinzipien umgesetzt sein können. Weiterhin ergeben sich nach Tilkov fünf Kernprinzipien für REST [Til11, S. 11]:

  1. Ressourcen mit eindeutiger Identifikation: Das Prinzip der eindeutigen Identifikation fordert, dass jede Ressource ihren eigenen URI hat, durch den sie anwendungsübergreifend eindeutig identifiziert wird. Die Ressource kann dabei eine einzelne Entität oder eine Menge von Entitäten repräsentieren. Ein URI ist eine ID innerhalb eines globalen Namensschemas.
  2. Verknüpfungen/Hypermedia: Weiteres Grundprinzip beim Hypermedia-Ansatz ist, dass Verknüpfungen anwendungsübergreifend funktionieren. Ressourcen werden mit anderen Ressourcen über Links miteinander verknüpft. Da das Namensschema global ist, kann jede Anwendung weltweit mit einer anderen Anwendung verknüpft werden.
  3. Standardmethoden: Damit Clients mit Ressourcen kommunizieren können, sollten alle Ressourcen das HTTP-Protokoll korrekt implementieren. Daher fordert das dritte Prinzip, dass jede Ressource einen Satz an Standardmethoden bzw. Verben unterstützt. Hierzu gehören meist die HTTP-Standardmethoden GET, PUT, POST und DELETE. Oftmals werden noch HEAD und OPTIONS unterstützt. Dadurch erhält man eine Schnittstelle mit fest definierten Methoden.
  4. Unterschiedliche Repräsentationen: Eine Ressource kann mehrere Repräsentationen für unterschiedliche Anwendungen zur Verfügung stellen. Man sieht nie die Ressource selbst, sondern nur ihre Repräsentation. Ein Ansatz von HTTP ist die Trennung von Verantwortlichkeiten (Separation of Concerns) für Daten und Operationen. Operationen in Form der zuvor genannten HTTP-Standardmethoden sind dabei gleich, aber die Daten können auf unterschiedliche Art und Weise repräsentiert werden (Content-Negotiation).
  5. Statuslose Kommunikation: REST schreibt vor, dass die Kommunikation grundsätzlich statuslos sein sollte. Ist es unbedingt erforderlich einen Zustand zu speichern, sollte dies Client-seitig geschehen oder vom Server in einen Ressourcenstatus umgewandelt werden. Gründe für Statuslosigkeit sind Skalierbarkeit und lose Kopplung.

Da jede Ressource einen weltweit eindeutigen Identifier in Form eines URIs erhält, kann man domänenübergreifend auf sie zugreifen. Daraus resultiert, dass auch Verknüpfungen zu abhängigen Ressourcen über Links anwendungs- und domänenübergreifend weltweit funktionieren. Aus der Forderung nach Statuslosigkeit ergibt sich, dass jede Anfrage/Antwort (Request/Response) völlig autark ist. Manchmal ist es jedoch sinnvoll, einen Zustand zu halten, um bestimmte Abläufe nicht unnötig wiederholen zu müssen. Dazu gehört insbesondere die Authentifizierung. Der Authentifizierungsvorgang kann je nach gewähltem Verfahren ein aufwändiger Prozess sein, der bei jeder Anfrage durchlaufen werden muss. Um dies zu umgehen, kann die einmal festgestellte Identität eines Clients in einem Cookie festgehalten werden. Ein Cookie ist eine clientseitige Ablage von Sitzungsinformationen in Form von Schlüssel-/Wert-Paaren. Cookies werden i. d. R. von Browsern unterstützt. Cookies verlieren i. d. R. ihre Gültigkeit, wenn einer der miteinander kommunizierenden Prozesse geschlossen wird.

Die Verwendung von Standardmethoden erleichtert die Schnittstellenbeschreibung und gewährleistet, dass User-Agents über Standard-Funktionalitäten auf eine Ressource zugreifen können. Populärster User-Agent ist der Browser zum Abrufen von Hypermedia-Dokumenten. Bei der Eingabe eines URIs in der Adresszeile, wird eine Anfrage mit der HTTP-Standardmethode GET (z. B. GET http://www.example.org/tasks HTTP/1.1) ausgeführt. Daneben werden der Anfrage noch weitere Headerinformationen hinzugefügt. Der Service, der die Ressource zur Verfügung stellt, versteht die Methode GET und sendet sie im Body der Antwort die Ressource im bevorzugten Repräsentationsformat.

Repräsentationsformate

Eine Ressource ist ein Datenobjekt, welches über einen URI eindeutig identifiziert werden kann. Eine Ressource kann in verschiedenen Repräsentationsformaten unter demselben URI angeboten werden. In welchem Repräsentationsformat die Ressource letztendlich übertragen wird, muss zwischen Client und Server “verhandelt” werden. Dieses Verhalten wird in RFC 2616 als Content Negotiation beschrieben [Fie99, Kapitel 12].

Das HTTP-Protokoll bietet Vorkehrungen für Content Negotiation, d. h. es können mehrere Repräsentationen einer Ressource angeboten werden. Es wird zwischen Server-Driven-Negotiation und Client-Driven-Negotiation unterschieden, d. h. entweder der Server oder der Client entscheidet über das übermittelte Repräsentationsformat [Fie99, Kapitel 12.1 und 12.2].

Multipurpose Internet Mail Extensions (MIME) ist ein Protokoll, das es erlaubt, verschiedene Dokumente unterschiedlicher Formate als eine einzige Nachricht zu verschicken. MIME ist in RFC 2045 [Fre961] und RFC 2046 [Fre962] standardisiert. Bei MIME steht eine Meta-Information, die die Codierung der Nachricht und ihre hierarchische Struktur beschreibt, als ASCII-Text im Nachrichten-Header. Die Kopf-(Header-)Information umfasst die MIME-Version, mit der die Nachricht erstellt wurde, den Typ des Nachrichteninhalts und die Art der Kodierung für den Nachrichtentransport [Fie99, Kapitel 19.4.1].

REST hat keine architektonischen Beschränkungen bzgl. der physikalischen Repräsentation von Ressourcen. Im Hinblick auf die unterschiedlichen Nutzerbedürfnisse ist das sinnvoll. Der Typ einer RESTful-Service-Ressource wird Medientyp genannt. Dieser Medientyp wird immer als MIME-Type im Content-Type-Header einer HTTP-Response angegeben. Die vier häufigsten Medienformate sind XML, Really Simple Syndication (RSS) / Atom Syndication Format, Extensible Hypertext Markup Language (XHTML) und Java Script Object Notation (JSON). Die Parameter des Content-Type-Header-Feldes sind in RFC 2045 spezifiziert [Fre961].

Hypertext Transfer Protocol HTTP

Der REST Architekturstil basiert auf dem HTTP-Protokoll, welches in RFC 2616 publiziert ist [Fie99]. HTTP ist ein offener und interoperabler Webstandard, der einen Standard-Weg für Anwender aufzeigt, miteinander zu interagieren. Diese Interaktionen basieren auf den Anforderungsmethoden bzw. Verben.

Die Kommunikation über HTTP zwischen Client und Server erfolgt über Nachrichten (Messages) im Klartextformat (Human-Readable Medium). Es gibt zwei Arten von Nachrichten: Die Anfrage (Request) vom Client an den Server und die Antwort (Response) als Reaktion vom Server zum Client. Eine Nachricht besteht aus zwei Teilen: Dem Nachrichtenkopf (Header) und dem Nachrichtenkörper (Body). Der Body enthält die Ressourcenrepräsentation, bzw. die Nutzdaten. Der Header enthält die Metainformationen der Nachricht, bzw. des Bodys, wie etwa verwendete Kodierungen oder den Inhaltstyp, damit dieser vom Client korrekt interpretiert werden kann [Fie99].

Uniform Resource Identifier (URI) sind eine Zeichenfolge, die eine Ressource weltweit eindeutig identifzieren. Der aktuelle Standard für URIs ist in RFC 3986 publiziert [Ber05]. URIs können absolut oder relativ zu einem Base-URI angegeben werden [Fie99, Kapitel 3.2].

Die generische URI-Syntax besteht insgesamt aus fünf Teilen, für die hier zu bearbeitende Aufgabe sind jedoch nur drei von Bedeutung: Scheme (Schema), Authority (Anbieter) und Path (Pfad).

Beispiel aus RFC 3986 [Ber05]:

foo://example.com:8042/over/there

_/ ________________/_________/

| | |

scheme authority path

Das Schema gibt den URI-Typ an, z. B. HTTP, HTTPS oder FTP. Die Authority ist ein optionaler Bestandteil einer URI, der eine Instanz innerhalb eines Domain Name Systems repräsentiert. Auf die Authority folgt ein weiterer Pflichtbestandteil: Der Path. Der Path enthält meist hierarchisch organisierte Angaben, die zusammen mit dem Abfrageteil eine Ressource identifizieren. Wenn eine Authority vorangestellt ist, muss sie mit einem Schrägstrich (“/”) beginnen.

HTTP-Anforderungsmethoden (HTTP-Verben)

Das HTTP-Protokoll beinhaltet eine erweiterbare Menge von Standardverben. Im Folgenden werden die hier relevanten Verben bzw. Methoden, die ein Client im Header des Requests angeben kann, kurz beschrieben [Fie99, Kapitel 9].

Methoden können zum einen sicher sein und/oder idempotent. Von einer sicheren Methode sprechen wir, wenn sie keine weiteren Aktionen als das reine Anfordern von Daten hervorruft. Typischerweise erfüllen dieses Kriterium die GET- und HEAD-Methoden. Idempotente Methoden können zwar Seiteneffekte verursachen, jedoch sind diese bei mehrmaligem Aufruf der Methode dieselben wie beim einmaligen Aufruf [Fie99, Kapitel 9.1].

  • GET

    Mit der GET-Methode fordert ein Client eine Ressourcenrepräsentation an, die unter dem angegebenen URI zu finden ist. Eine der wichtigsten Eigenschaften von GET ist, dass man das Ergebnis eines GET-Requests cachen kann, wenn bestimmte Voraussetzungen erfüllt sind. Wenn die im Request angeforderte Ressource im Response-Body enthalten ist, ist der Response-Code 200 (OK). Die GET-Methode erzeugt keine Seiteneffekte, d. h. sie verursacht keine Änderungen an anderen Ressourcen. Außerdem ist GET idempotent, d. h. das mehrmalige Ausführen einer Methode führt zum selben Ergebnis, wie das einmalige Ausführen der Methode [Fie99, Kapitel 9.3].

  • HEAD

    Die HEAD-Methode ist äquivalent zur GET-Methode, wobei aber nicht die Ressourcenrepräsentation selber, sondern nur ihre Meta-Informationen abgerufen werden. HEAD liefert keinen Message-Body in der Response-Nachricht zurück, wird aber trotzdem mit 200 (OK) quittiert. HEAD ist genau wie GET sicher bzw. erzeugt keine Seiteneffekte [Fie99, Kapitel 9.4].

  • POST

    Die POST-Methode wird benutzt, um auf dem Server eine neue Ressource zu erzeugen. Dabei ist die neue Ressource die untergeordnete Ressource der im Request-URI angesprochenen Ressource. Der Response-Status-Code für eine erfolgreich erzeugte Ressource sollte 201 (Created) sein. Weiterhin sollte die Response-Message einen Location-Header mit dem URI der neu erzeugten Ressource enthalten. Wenn die Methode nicht zu einer adressierbaren Ressource führt, sind die verwendeten Response-Codes 200 (OK) oder 204 (No Content), je nachdem, ob der Response einen Body mit einem beschreibenden Ergebnis liefert. Wenn die Aktion nicht sofort ausgeführt werden kann, liefert der Server ein 202 (Accepted). POST ist weder idempotent noch sicher [Fie99, Kapitel 9.5].

  • PUT

    Die PUT-Methode wird benutzt, um eine bestehende Ressource auf dem Server unter dem angegebenen URI zu speichern oder zu aktualisieren. Der Unterschied zwischen POST und PUT ist, dass der URI in der Clientanforderung unterschiedlich interpretiert wird. Der URI in einem PUT gibt die Adresse an, unter der die Ressource, die im Request mitgeschickt wird, ansprechbar sein soll. Der URI in einem POST dagegen spezifiziert die Ressource, an die die gesendete Ressource angefügt wird, und nicht den URI der gesendeten Ressource. Der Response-Conde für eine modifizierte Ressource sollte 200 (OK) oder 204 (No Content) sein. PUT ist idempotent [Fie99].

  • DELETE

    Die DELETE-Methode erlaubt es, eine Ressource unter dem angegebenen URI zu löschen. Eine erfolgreiche Response sollte 200 (OK) sein, wenn er eine Entität enthält, welche den Status beschreibt oder 202 (Accepted), wenn die Aktion noch nicht ausgeführt wurde. Wenn die Aktion ausgeführt wurde, aber keine Entität mitgesendet wird mit 204 (No content) geantwortet. DELETE ist ebenfalls idempotent [Fie99].

  • PATCH

    Die PUT-Methode ist so definiert, dass sie eine Ressource vollständig überschreibt. Die PATCH-Methode wird genutzt, um eine Ressource nur partiell zu überschreiben. Der Satz Änderungen wird in einem Format bereitgestellt, welches man Patch-Dokument nennt. Die Ressource wird nur modifiziert und nicht überschrieben. PATCH ist weder sicher noch idempotent. Der Response-Code ist bei erfolgreicher Modifizierung der Ressource 204 (No Content), weil der Message Body leer bleibt. Je nach Fehlerfall können die Response-Codes 404 (Not Found), 409 (Conflict) oder 412 (Precondition Failed) auftreten [Dus10].

Header-Fields werden im Header einer Nachricht transportiert. Hierbei unterscheidet man zwischen Request- und Response-Header. Im Folgenden sollen die hier wichtigsten Header kurz aufgeführt werden [Fie99].

  • Accept und Content-Type

    Der Accept-Header im Request wird genutzt, um Medientypen anzugeben, die der Client versteht. Es können auch mehrere Medientypen angegeben werden. Der Content-Type-Header im zugehörigen Response gibt den Medientyp der im Body enthaltenen Ressource an, bzw. im Falle der HEAD-Methode den Medientyp, der bei der GET-Methode zurückgeliefert worden wäre [Fie99].

  • Authorization und WWW-Authenticate

    Im Authorization-Header schickt der Client seine Authentifizierungsinformationen an den Server. Dies kann initial erfolgen oder infolge eines 401 (Unauthorized) Response. Der zugehörige WWW-Authenticate-Header des Response muss in einem 401 (Unauthorized) Response angegeben werden und enthält mindestens eine Challenge, die ein Authentifizierungsschema angibt und weitere Parameter [Fie99].

  • Location

    Im Location-Response-Header wird der Client zu einem URI umgeleitet, der nicht dem angefragten URI entspricht. Für 201 (Created) Responses ist der angegebene URI die URI der neuen Ressource. Der URI der neuen Ressource muss absolut angegeben werden [Fie99].

 

[Bern96] Tim Berners-Lee, “The World Wide Web: Past, Present and Future,” IEEE Computer, Oct. 1996.

[Fie00] Roy Thomas Fielding. (2000) Architectural Styles and the Design of Network-based Software Architectures. [Online]. http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

[Til11] Stefan Tilkov, REST und HTTP – Einsatz der Architektur des Web für Integrationsszenarien. Heidelberg: dpunkt.verlag, 2011.

[Fie99] R. Fielding et al. (1999, June) RFC 2616 – Hypertext Transfer Protocol — HTTP/1.1. [Online]. http://tools.ietf.org/html/rfc2616

[Fre961] N. Freed and N. Borenstein. (1996, Nov.) RFC 2045 – Multipurpose Internet Mail Extensions. [Online]. http://www.ietf.org/rfc/rfc2045.txt

[Fre962] N. Freed and N. Borenstein. (1996, Nov.) RFC 2046 – Multipurpose Internet Mail Extensions. [Online]. http://www.ietf.org/rfc/rfc2046.txt

[Ber05] T. Berners-Lee, R. Fielding, and L. Masinter. (2005, Jan.) RFC 3986 – Uniform Resource Identifier (URI): Generic Syntax. [Online]. http://tools.ietf.org/html/rfc3986

[Dus10] L. Dusseault and J. Snell. (2010, Mar.) RFC 5789 – PATCH Method for HTTP. [Online]. http://tools.ietf.org/html/rfc5789

Leave a Reply