Web-Service-APIs Contest – Teil 3 Konzept, Aufbau und Funktionsweise von REST

Representational State Transfer, kurz REST, ist ein modernes, zu SOAP oder RPC alternatives Programmierparadigma für Web-Services. AWS, VMware, Azure und andere Cloud-Anbieter setzen heute fast ausschließlich auf REST. Es kommt mit weniger Ressourcen aus und lässt sich einfacher erlernen bzw. anwenden. Hat REST also nur Vorteile?

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH

Confluent Germany GmbH

Programmierparadigma, Aufbau und Funktionsweise von REST unterscheiden sich deutlich von den althergebrachten Technologien. So versteht sich REST als eine Art Abstraktion der gesamten Struktur und des Verhaltens des World Wide Web selbst. Zudem wollten die Entwickler mit REST einen (z. B. im Vergleich zu SOAP) völlig anderen Architekturstil schaffen, der den Anforderungen des modernen World Wide Web besser gerecht wird.

Eine der Besonderheiten dieses „anderen“ Architekturstils besteht beispielsweise in der Forderung nach einer einheitlichen Schnittstelle. Dies äußert sich bei REST so, dass es in den URLs keinerlei Methodeninformation kodiert, ganz im Gegensatz zu SOAP. Vielmehr gibt die URL bei REST nur Ort und Namen der Ressource an – aber nicht die Funktionalität, die der Web-Dienst zu der Ressource anbietet.

SOAP hingegen verbindet sich in einer Session mit dem kompletten Endpunkt. Das funktioniert natürlich nur deshalb, weil das World Wide Web ja bereits den Löwenanteil der für REST benötigten – oder besser gesagt von REST vorausgesetzten – Infrastruktur bereitstellt. Hierzu zählen unter anderem Applikationsserver, HTML-/XML-Parser und inzwischen zahllose weitere REST-fähige Web-Dienste.

So funktioniert REST

Um den Ansatz von REST insbesondere im Vergleich zu SOAP besser zu verstehen, muss man etwas ausholen. Wie im ersten Web-Services-API-Beitrag skizziert, war seit der Jahrtausendwende das Simple Object Access Protocol (SOAP) das Protokoll der Wahl für Web-Dienste.

Web-Service-API Contest – Teil 1

Web-Dienste und Service-orientierte Architektur

Dank SOAP war/ist ein Client in der Lage, die Methoden eines serverseitigen Objekts direkt aufzurufen. Wie geschildert, funktionierte das durch den Austausch sehr komplexer XML-Nachrichten über HTTP (oder SMTP, FTP etc.) – wobei die Kombination aus XML und HTTP dafür sorgt, dass SOAP unabhängig von Plattform und Programmiersprache funktioniert. Ein in C++ geschriebener Client könnte also Methoden von Server-seitigen Java-Objekten aufrufen.

Was ursprünglich praktisch war, offenbarte seine Schwächen erst im Laufe der Jahre. Eines der Hauptprobleme von SOAP ist der zum Teil riesige Overhead, also das schlechte Verhältnis zwischen (vielen) Metadaten und (wenigen) Nutzdaten. Zudem kosten das Zusammenbauen der XML-Nachrichten am Client und das Zerlegen auf der Server-Seite Zeit, weil es sich dabei um rechenintensive Prozesse handelt.

Web-Service-APIs Contest – Teil 2

Entstehung, Aufbau und Funktionsweise von SOAP

Erschwerend kommt hinzu, dass die großen Software-Hersteller den anfangs noch unkomplizierten Standard nach und nach um immer mehr Substandards erweitert haben. Heute gibt es bekanntlich mehrere hundert solcher „WS-*“-Standards.

Grundprinzipien von REST-Architekturen

Die „Sehnsucht“ der Entwickler nach einem einfacheren Verfahren ist also nachvollziehbar. So entstand der so genannte REST-Architekturstil, wobei REST für „Representational State Transfer“ steht. Der Begriff wurde im Jahr 2000 von Roy Fielding ins Leben gerufen. Dahinter steht der Anspruch, dass der Architekturstil selbst unabhängig von jeglichen konkreten Protokollen funktionieren soll, auch wenn zur Implementation REST-geeigneter Architekturen in der Regel ebenfalls HTTP verwendet wird.

Die Kernidee bei REST ist das Konzept der Ressource, wobei eine „Ressource“ als so genannter Medientyp abgebildet wird, sozusagen die Repräsentation der Ressource ist. Alles was in REST adressierbar ist, ist eine Ressource wie z. B. der Tweet eines Twitter-Nutzers oder das S3-Bucket eines AWS-Nutzers.

Für eine im REST-Architekturstil verwendbare Ressource gelten folgende Prinzipien:

• 1. Adressierbarkeit: Jede Ressource muss sich mit Hilfe eines eindeutigen Unique Ressource Identifiers (kurz URI) identifizieren lassen. So lässt sich z. B. in REST eine Bestellung mit der Bestellnummer 12345 mithilfe der URI http://ws.meinedomain.tld/orders/12345 adressieren.

• 2. Zustandslosigkeit: Das zweite wichtige Prinzip von REST besteht darin, dass die Kommunikation immer zustandslos sein muss. Bei REST gibt es also keine mit Sessions und Cookies realisierten Benutzersitzungen. Das bedeutet im Umkehrschluss, dass bei jeder Anfrage sämtliche erforderlichen Informationen erneut mitgesendet werden. Der Vorteil (und Hauptgrund) der Zustandslosigkeit von REST-Services ist die einfache Skalierbarkeit. Gibt es nämlich keine Sessions, lassen sich mehrere Anfragen eines Clients problemlos auf verschiedene Server verteilen.

• 3. Entkopplung von Ressourcen und Repräsentation: Bei REST können verschiedene Repräsentationen einer Ressource existieren. So kann z. B. ein Client eine Ressource explizit im JSON- oder auch XML-Format anfordern.

• 4. Vereinheitlichte Schnittstelle: Bei REST wird stets über einen einheitlichen Satz von Standardmethoden auf eine Ressource zugegriffen, wie z. B. die Standard-HTTP-Methoden GET, POST, PUT usw.

REST und HTTP-Operationen

Im Zusammenhang mit REST werden oft die Standard-Methoden von HTTP GET, POST, PUT und DELETE zitiert. Dies ist darin begründet, dass Software-Hersteller REST-Dienste in der Regel auf Basis von HTTP umsetzen, weil das Protokoll als Internet-Fundament maximal verbreitet ist. So funktioniert ja in der Praxis jeder Seitenaufruf eines Webbrowsers auf der GET-Methode oder der POST-Methode beim Versenden eines Formulars.

Für HTTP spricht aber auch, dass es trotzdem recht einfach aufgebaut und zudem in nahezu jeder Firewall offen ist. Die wichtigsten Methoden und Operatoren sollen im Folgenden kurz erklärt werden, auch wenn die weitaus Meisten davon von den gängigen Browsern gar nicht verwendet werden.

• Mit GET greift man in REST lesend auf Ressourcen zu. Dabei ist in REST fest definiert, dass GET-Anfragen niemals Daten auf dem Server verändern.

• Eine neue Ressource lässt sich mit einem POST-Request erstellen, etwa mit http://ws.meinedomane/orders eine neue fortlaufende Bestellnummer.

• Anders kann mit einem PUT-Request eine Ressourcen erstellt oder bearbeitet werden, bei der der URI bereits bekannt ist. So würde z. B. eine PUT-Request an http://ws.mydomain.tld/orders/12345 eine Bestellung mit der Bestellnummer 12345 anlegen, wenn diese noch nicht existiert oder selbige bearbeiten, wenn sie existiert.

• Löschen lassen sich Ressourcen mit einem DELETE-Request.

Um beim Beispiel mit der Bestellnummer zu bleiben, könnte z. B. der URI http://ws.meinedomane.tld/openorders den Zugriff auf die offenen Bestellungen eines webbasierten Warenwirtschaftssystems ermöglichen. Für eine vollständige Liste aller offenen Bestellungen genügt dann ein GET-Request an diese URI.

Mit dem Accept-Request informiert dabei der Client den Server, dass er die Antwort im JSON-Format erwartet. Er könnte beispielsweise im Header auch

verwenden.

Vorteile gegenüber SOAP

Fassen wir zusammen: SOAP war und ist in den Augen vieler Entwickler schwerfällig und schwer zu handhaben. Nutzt man SOAP etwa in JavaScript, muss für eine an sich sehr einfache Aufgaben sehr viel Code geschrieben werden, weil die benötigte XML-Struktur (ohne WSDL) jedes Mal neu erstellt werden muss.

In bzw. mit REST hingegen genügt in vielen Fällen eine einfach URL (statt XML zum Formulieren einer Anfrage verwenden zu müssen). Auch wenn REST-Entwickler in einigen Fällen zusätzliche Informationen in besonderer Weise bereitstellen müssen, verlassen sich die meisten Web-Services darauf, die benötigten Informationen aus dem URI-Ansatz zu gewinnen. REST kann alleine mit den vier HTTP-„Operationen“ GET, POST, PUT und DELETE fast alle Aufgaben ausführen und muss zum Bereitstellen der Antwort ebenfalls kein XML verwenden, obwohl es wie oben gesehen möglich ist.

REST-Dienste können Antworten auch in der JavaScript Object Notation (JSON, am häufigsten verwendet), RSS oder CSV ausgeben, je nachdem in welcher Form der Entwickler es benötigt. Dieser verwendet einfach jene Sprache, die er für seine Anwendung benötigt.

Web-Service-APIs Contest – Teil 4

Anwendungsbeispiele mit REST

(ID:44613995)