REST: Representational State Transfer

Das World Wide Web besteht aus weit mehr Komponenten, als Internetnutzer beim Aufruf einer Website oder -applikation wahrnehmen. So greifen beispielsweise nicht nur menschliche User, sondern auch maschinelle Benutzer auf die Daten und Inhalte verschiedenster Webprojekte zu. Die Voraussetzung ist, dass der jeweilige Betreiber sein Projekt überhaupt anderen Anwendungen zugänglich macht, indem er einen entsprechenden Webservice zur Verfügung stellt. Ein gutes Beispiel stellt der Kurznachrichtendienst Twitter dar: Dank eines entsprechenden Webservices können beliebige Anwendungen Tweets im Namen eines Twitter-Users auslesen oder gar schreiben.

Um einen solchen Webservice zu implementieren, gibt es verschiedene Techniken wie das Abfrageprotokoll Remote Procedure Call (RPC), das Netzwerkprotokoll SOAP oder auch das Programmierparadigma Representational State Transfer (REST), um das es im Folgenden geht.

Domain kaufen
Registrieren Sie Ihre perfekte Domain
  • Inklusive Wildcard-SSL-Zertifikat
  • Inklusive Domain Lock
  • Inklusive 2 GB E-Mail-Postfach

Das steckt hinter REST

Der Begriff „Representational State Transfer“ stammt aus einer von 2000 datierenden Dissertation von Roy Fielding, einem der Hauptentwickler zahlreicher Webstandards. Er beschreibt in abstrahierter Form die Architektur, die dem World Wide Web (HTTP-Protokoll, HTML- und XML-Parser, Web- und Application-Server etc.) zugrunde liegt. Prinzipiell ist die REST-Architektur allerdings nicht von spezifischen Protokollen abhängig. Ihr zentrales Konzept sind Ressourcen, die nach Fielding folgende Anforderungen erfüllen müssen:

  • Adressierbarkeit: Jede Ressource, z. B. eine Bestellung, ein Produkt oder ein Artikel, muss über einen Unique Resource Identifier (URI) identifiziert werden können.
  • Einheitliche Schnittstelle: Auf jede Ressource muss einfach und einheitlich mithilfe von Standardmethoden zugegriffen werden können. Beispiele sind HTTP-Methoden wie „GET“, „POST“ oder „PUT“.
  • Client-Server-Struktur: Generell gilt das Client-Server-Prinzip, nach dem ein Server einen Dienst zur Verfügung stellt, der bei Bedarf von einem Client angefordert werden kann.
  • Zustandslosigkeit: Die Kommunikation zwischen Server und Clients ist zustandslos. Das heißt, dass alle ausgetauschten Nachrichten sämtliche Informationen enthalten, die notwendig sind, um sie zu verstehen. Der Server speichert keine Zusatzinformationen zwischen zwei Nachrichten wie beispielsweise in Form von Sessions. Die Zustandslosigkeit macht REST-Services sehr einfach skalierbar, da eingehende Anfragen im Rahmen von Lastverteilung unkompliziert auf verschiedene Server verteilt werden können.
  • Unterschiedliche Repräsentationen der Ressourcen: Jede Ressource kann unterschiedliche Darstellungsformen besitzen. Je nachdem, was der Client anfordert, muss sie beispielsweise in verschiedenen Sprachen oder Formaten wie HTML, JSON oder XML ausgeliefert werden können.
  • Hypermedia: Die Bereitstellung der Ressourcen geschieht über Hypermedia, z. B. in Form von „href“- und „src“-Attributen in HTML-Dokumenten oder für die jeweilige Schnittstelle definierten JSON- bzw. XML-Elementen. Somit navigiert der Client einer REST-API nach dem Prinzip „Hypermedia as the Engine of Application State (HATEOAS)“ ausschließlich über URLs, die der Server bereitstellt und benötigt kein zusätzliches Wissen über die Schnittstelle.

Diese strikten Vorgaben der REST-Architektur ermöglichen die Entwicklung gut strukturierter Dienste, die einfach zu integrieren sind und über ein einheitliches Protokoll (HTTP) kommunizieren. Dank der ressourcenorientierten Struktur entfällt bei der Konzipierung eines REST-Webservices außerdem die Suche nach anwendungsspezifischen Protokollen, die bei vergleichbaren Alternativen wie SOAP notwendig ist.

So funktioniert die Gestaltung eines REST-Services

Um einen REST-Webservice zu realisieren, werden hauptsächlich HTTP und dessen verschlüsselte Version HTTPS verwendet. Das ist einerseits auf dessen enorme Verbreitung zurückzuführen, dank der es in so gut wie jeder Firewall offen ist; andererseits ist das zustandslose Hypertext Transfer Protocol auch vergleichsweise einfach aufgebaut, ohne dass spezielle Implementierungen vorausgesetzt werden. Zudem definiert der HTTP-Standard bereits ein ganzes Set an Befehlen, mit denen auf Ressourcen zugegriffen werden kann:

HTTP-Methode (Befehl) Beschreibung
GET Fordert die jeweilige Ressource vom Server an, ohne deren Zustand am Server zu verändern
POST Erstellt eine neue Ressource unterhalb der angegebenen Ressource, die vom URI automatisch adressiert wird; kann außerdem verwendet werden, um bestehende Ressourcen zu modifizieren
HEAD Fordert nur den Header der jeweiligen Ressource vom Server an, um z. B. die Gültigkeit einer Datei zu überprüfen
PUT Legt die angegebene Ressource auf dem Server an oder modifiziert eine bestehende
PATCH Modifiziert einen Teil der angegebenen Ressource
DELETE Löscht die jeweilige Ressource
TRACE Gibt die Anfrage so zurück, wie sie der Webserver erhält, um Veränderungen auf dem Weg zu selbigem zu ermitteln
OPTIONS Zeigt eine Liste der vom Server unterstützten Methoden
CONNECT Leitet die Anfrage durch einen SSL-Tunnel, in der Regel, um eine Verbindung über einen Proxyserver herzustellen

Die Befehlspalette kann durch die Implementierung weiterer Protokolle vergrößert werden. Typisch ist hier vor allem das WebDAV-Protokoll, das die Methoden COPY (Ressource kopieren), MOVE (Ressource verschieben), LOCK (Ressource sperren), UNLOCK (Ressource freigeben) und MKCOL (Verzeichnis erstellen) hinzufügt.

Webhosting
Top-Hosting für Ihre Website
  • Flexibel: Hosting, das jedem Website-Traffic standhält
  • Verlässlich: Inklusive 24/7-Support und persönlicher Beratung
  • Sicher: Kostenloses SSL-Zertifikat, DDoS-Schutz und Backups

Für welche Webservices eignet sich die REST-Architektur?

Typischerweise sind vor allem die Standardmethoden GET, POST, PUT/PATCH und DELETE bei der Entwicklung eines REST-Services via HTTP im Einsatz, was die Annahme zulässt, dass sich die Architektur nur für den Aufbau simpler Datenverwaltungen eignet. Und auch der Grundsatz der Zustandslosigkeit der REST-Ressourcen scheint die Möglichkeiten der Architektur stark einzuschränken. Mit der richtigen Behandlung der Ressourcen ermöglicht das REST-Interface allerdings weit mehr als das simple Einfügen von Datensätzen, wie die folgenden Beispiele beweisen:

  • Webservices mit Transaktionsverarbeitung: Um Webservices mit Transaktionen zu realisieren, ist ein Transaktionsmanager unerlässlich. Da alle Ressourcen aufgrund der Zustandslosigkeit immer ohne Zusatzinformationen zwischen zwei Anfragen, also ohne die Zuweisung von Sitzungen, gespeichert werden, ist die Umsetzung mit REST auf zwei Möglichkeiten beschränkt:

    • Die Ressourcen werden so gestaltet, dass Transaktionen innerhalb einer Anfrage verarbeitet werden können.

    • Es wird eine Ressource angelegt, die Anträge auf Transaktionen verwaltet. Jede Anfrage, die dieser Transaktionsmanager-Ressource gestellt wird, erzeugt automatisch eine weitere Ressource, die über einen URI identifiziert wird und eine zusammenhängende Transaktion repräsentiert. Veränderungen können in der Folge als Repräsentationen dieser Ressource auf dem Server abgelegt werden. Eine weitere Anfrage an den Transaktionsmanager schließt die Transaktion ab
  • Asynchrone Webservices: Für bestimmte Webservices ist es wünschenswert, dass Anfrage und Antwort zeitlich entkoppelt sind. Da HTTP für diesen Fall keinerlei Mechanismen bietet, bleibt einzig die Option die Abarbeitungen der Anfragen als Serviceanbieter selbst zu verwalten und auf gezielte Anfrage der Nutzer weiterzuleiten.
  • Webservices mit weitreichender Interoperabilität: REST-Services zeichnen sich durch ihre große Flexibilität aus, die zum einen aufgrund der Konzentration auf ein einziges zugrundeliegendes Protokoll, zum anderen aus der direkten Adressierung der einzelnen Ressourcen resultiert. Insbesondere mobile Clients profitieren von den geringen Anforderungen der REST-Architektur. Die einfache Erreichbarkeit der Ressourcen bewirkt außerdem, dass diese ohne weiteres von Suchmaschinen gefunden werden können.

Webservices mit REST programmieren – Fazit

Das REST-Gerüst liefert hervorragende Mittel zur Konzipierung und Umsetzung von Webservices verschiedenster Art. Dank der Tatsache, dass nahezu alle Geräte das Hypertext Transfer Protocol unterstützen, können sowohl Desktop- als auch mobile Clients mühelos und ohne zusätzliche Implementierungen mit dem REST-Interface arbeiten. Das Ergebnis sind Webservices, die durch ein hohes Maß an

  • Plattformunabhängigkeit,
  • Skalierbarkeit,
  • Performance,
  • Interoperabilität
  • und Flexibilität

überzeugen. Die Nutzung erfordert jedoch auch das entsprechende Know-how, wobei vor allem die Interaktion zwischen den einzelnen, zustandslosen Ressourcen sehr komplex und schwer zu bewerkstelligen ist. Wer bereits mit Alternativen wie dem Protokoll SOAP gearbeitet hat, wird durch die gänzlich anderen und ungewohnten Ansätze zum Umdenken gezwungen sein – besitzt am Ende aber einen Service, der sehr viel leichter in unerwarteten Kontexten nutzbar ist.

Domain kaufen
Registrieren Sie Ihre perfekte Domain
  • Inklusive Wildcard-SSL-Zertifikat
  • Inklusive Domain Lock
  • Inklusive 2 GB E-Mail-Postfach
War dieser Artikel hilfreich?