Web-Service-APIs Contest – Teil 3

Konzept, Aufbau und Funktionsweise von REST

| Autor / Redakteur: Thomas Drilling / Stephan Augsten

Der Konkurrenzkampf zwischen SOAP und REST wird seit Jahren geführt. Die „Anbieterseite“ tendiert dabei immer weiter in Richtung REST.
Der Konkurrenzkampf zwischen SOAP und REST wird seit Jahren geführt. Die „Anbieterseite“ tendiert dabei immer weiter in Richtung REST. (Bild: Thomas Drilling)

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?

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-Dienste und Service-orientierte Architektur

Web-Service-API Contest – Teil 1

Web-Dienste und Service-orientierte Architektur

08.05.17 - Web Services spielen mittlerweile eine große Rolle bei der Kommunikation zwischen IT-Systemen und -Komponenten. Denn serviceorientierte Architekturen, kurz SOA, bilden für nahezu alle professionellen Unternehmensanwendungen die Basis. Was bedeutet das? lesen

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.

Entstehung, Aufbau und Funktionsweise von SOAP

Web-Service-APIs Contest – Teil 2

Entstehung, Aufbau und Funktionsweise von SOAP

15.05.17 - REST und SOAP sind die beiden aktuell wichtigsten Web-Service-APIs. Ob man das fast 20 Jahre alte SOAP oder den Newcomer REST nutzen sollte, hängt von verschiedenen Faktoren ab. Wir starten eine systematische Bestandsaufnahme mit SOAP. lesen

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.

Ressource versus Endpoint: die Protokoll-Ebenen von REST und SOAP im Vergleich.
Ressource versus Endpoint: die Protokoll-Ebenen von REST und SOAP im Vergleich. (Bild: Thomas Drilling)

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.

GET /openorders HTTP/1.0
Accept: application/json

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

Accept: text/xml

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.

Anwendungsbeispiele mit REST

Web-Service-APIs Contest – Teil 4

Anwendungsbeispiele mit REST

31.05.17 - Immer mehr Anbieter von Web-Services wechseln von SOAP zu REST. Große Cloud-Anbieter wie Amazon und Azure bieten gar beides an, wenngleich sich der Fokus immer mehr zu REST verlagert. Wie REST-Aufrufe komponiert und die zugehörigen Responses analysiert werden, zeigt dieser Beitrag am Beispiel eines der zahlreichen Anbieter von Wetter-Apps, deren APIs ebenfalls meist auf REST basieren. lesen

Kommentare werden geladen....

Kommentar zu diesem Artikel

Der Kommentar wird durch einen Redakteur geprüft und in Kürze freigeschaltet.

Anonym mitdiskutieren oder einloggen Anmelden

Avatar
Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
  1. Avatar
    Avatar
    Bearbeitet von am
    Bearbeitet von am
    1. Avatar
      Avatar
      Bearbeitet von am
      Bearbeitet von am

Kommentare werden geladen....

Kommentar melden

Melden Sie diesen Kommentar, wenn dieser nicht den Richtlinien entspricht.

Kommentar Freigeben

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Freigabe entfernen

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Kontaktieren Sie uns über: support.vogel.de/ (ID: 44613995 / APIs)