Was ist ein RESTful Web-Service?

Keylearnings:

• Was ist ein Web Service?
• Was ist der Unterschied zwischen SOAP und RESTful Web Services?
• Was ist ein RESTful Web Service?
• Was ist der Unterschied zwischen Producers und Consumers?
• Was ist der Unterschied zwischen Collection und Resource URL’s.
• Was bedeutet HATEOS?

Was hat das Internet groß gemacht?

Katzenbilder!

Okay, nicht allein.

Aber wir sind der Sache auf der Spur.

Denn was sind Katzenbilder?

Richtig! Katzenbilder sind Daten.

Und Daten sind die Helden des Internet. So in etwa wie Batman aus Gotham City, Obelix aus Galien und Dennis aus Hürth.

Das Internet ist cool, weil es uns ermöglicht jederzeit auf eine große Menge von Daten zu zugreifen. Ob es sich hierbei um die aktuelle Wettervorhersage, die neusten Sportergebnisse oder eben Katzenbilder handelt ist egal!

So nutzt der Ottonormal-Verbraucher das Internet!

Vergiss für einen Moment, dass du ein Entwickler bist. Wie verwendest du das Internet?

Möglicherweise hast du jetzt ein Bild im Kopf wie du vor deinem Browser sitzt und eine Webseite wie die von Amazon, Google oder Wikipedia konsumierst.

Auf jeden Fall ist es ein Mensch, der sich die aufbereiteten Daten auf einer Webseite ansieht.

So nutzt der Entwickler das World Wide Web!

Jetzt erinnere dich daran, dass du ein Programmierer bist! Plötzlich fallen dir viele weitere Möglichkeiten ein wie du die Daten des Internets für dich nutzen kannst.

So kannst du dir z.B. sehr gut vorstellen wie du die Daten des Wetterdienstes in deiner selbst erstellten Jogging-App verwenden kannst.

In diesem Fall ist der Konsument der Daten also kein Mensch mehr, sondern eine Software.

Und genau an diesem Punkt setzen die Web-Services an.

Web-Services sind Dienste im Web mit denen man Rohdaten austauschen kann.

Diese Rohdaten können von unterschiedlichem Format sein. Sehr beliebte Formate sind das XML und das JSON Format.

Kennst du dieses Facebook? Ja ganau! Das Ding mit den blauen Seiten.

Die haben an dich gedacht und bieten dir eine eigene URL an, über die du auf deren Services zugreifen kannst. Nämlich https://developers.facebook.com.

Über diese URL hast du Zugriff auf Services, mit denen du dich bei Facebook anmelden, posten und Freundeslisten auslesen kannst.

Damit können deine Programme also alles das machen, was du normalerweise mit Maus und Tastatur per Hand durchführst wenn du bei Facebook eingeloggt bist.

Moment! Wir haben also bei Facebook für jeden Service (posten, Freundschaftsanfragen etc.) eine eigen URL?

So ist es! Das ist für Web-Services allerdings nicht selbstverständlich.

Genau genommen sprechen wir hier bereits von einer speziellen Art von Web-Service. Nämlich einem sogenannten RESTful Web-Service.

Hierbei steht REST für die Abkürzung Representational State Transfer.

Die Sammlung aller REST Services auf einem Server nennen wir REST API. Hierbei steht die Abkürzung API für Application Programming Interface.

Aber langsam. Sehen wir uns das mal genauer an.

SOAP und RESTful Web-Services

Um Web-Services zu realisieren haben sich smarte Menschen zusammengesetzt und sich entsprechende Konzepte ausgedacht.

Aktuell sind insbesondere zwei Arten von Web-Services in aller Munde. Und zwar SOAP und REST.

Beide haben gemeinsam, dass zwei Parteien miteinander kommunizieren. Ein Client und ein Server.

Der Server stellt einen Dienst zur Verfügung, den der Client verwenden kann.

Ähnlich wie wir in JAVA bei einer Methode mit Hilfe der Methodensignatur festlegen, welchen Datentyp die Methode verarbeitet (Parameterliste) und vom welchem Typ die zurückgelieferten Daten (Rückgabewert) sind.

Müssen wir auch bei einem Web-Service festlegen, welche Art von Daten der Server verarbeitet und zurückliefert.

Bei einem SOAP Web-Service definieren wir dies mit Hilfe der sogenannten Web Service Description Language (WSDL). Die Syntax der WSDL folgt einer durch das World Wide Web Consortiums (W3C) festgelegten Spezifikation.

Außerdem kann bei einem auf SOAP basierten Web-Service der Datenaustausch zwischen Server und Client nur mithilfe von XML Daten geschehen wohingegen wir bei einem REST Web-Service bei der Auswahl des Datenformats im wesentlichen frei sind.

Ein REST Web-Service hingegen basiert auf dem http Protokoll und verwendet die hierin festgelegten Regeln.

Insbesondere spielen hierbei die Metadaten im Kopf der Client-Anfrage an den Server, bzw. im Kopf der Antwort des Servers an den Client eine wichtige Rolle.

Im folgenden ein Beispiel wie eine Serverantwort aussehen könnte. Die Metadaten des Kopfes befinden sich in den Zeilen 1-15.

1: HTTP/1.1 200 OK
2: Date: Mon, 03 Oct 2016 12:28:53 GMT
3: Server: Apache/2.2.14 (Win64)
4: Last-Modified: Mon, 03 Oct 2016 13:15:56 GMT
5: ETag: "34aa387-d-1568eb00"
6: Vary: Authorization,Accept
7: Accept-Ranges: bytes
8: Content-Length: 88
9: Content-Type: text/html
10: Connection: Closed

11: <html>
12: <body>
13: <h1>Hello, World!</h1>
14: </body>
15: </html>

Diese Metadaten enthalten unter anderem den sogenannten Content Type, der festlegt vom welchen Typ die zwischen Client und Server kommunizierten Daten sind.

Bei einer Anfrage eines Web-Browser an einen Server, liefert der Server beispielsweise Daten im HTML Format an den Client zurück. Daher entspricht der Content-Type in diesem Fall „text/html“.

Da das http Protokoll ein zentraler Bestandteil des Word Wide Webs ist, erklärt dies die zunehmende Beliebtheit von RESTful Web-Services innerhalb von Web Anwendungen.

Im folgenden wollen wir uns auf Web-Services vom REST Typ konzentrieren.

Was ist ein RESTful Web-Service

Im folgenden wollen wir uns die Konzepte, auf denen ein RESTful Web-Service basiert genauer ansehen.

Ein besonderes Merkmal von REST Web-Services ist die Ressourcen-Gebundenheit.

Um einen von einem Server angebotenen Dienst aufzurufen verwenden wir bei RESTful Web-Services keine Verben sondern geben lediglich den Ort an, an welchem der Dienst zu Verfügung steht.

Hierbei wird der Ort, an dem eine Ressource bereitsteht wie beim http Protokoll üblich durch eine URL (Uniform Resource Locator) angegeben.

Nicht klar?

Okay, schauen wir uns ein Beispiel an.

Nehmen wir an wir möchten einen REST Web-Service Abfragen, der uns das Wetter für Koblenz liefert.

Eine typische URL für diesen Aufruf wäre.

http:\\www.wetterfrosch.com\wetterauskunft?stadt=koblenz

Diese URL besteht aus drei wichtigen Bestandteilen.

Der erste Teil http:\\www.wetterfrosch.com entspricht der Domäne, die von einem Nameserver in eine IP-Adresse aufgelöst wird, mit der wir den Server unserer Wetterauskunft im Internet ausfindig machen können.

Als nächstes folgt mit \wetterauskunft eine Ortsangabe, mit der wir den angeforderten Dienst auf dem Server ansprechen. Diese Ortsangabe können wir vergleichen mit dem Namen einer Methode, die wir aufrufen wollen.

Den  letzten Teil können wir mit den Argumenten vergleichen, die wir an eine Methode übergeben. Im RESTful Web-Service Jargon sprechen wir von QueryParametern, welche mit Hilfe eines ? eingeleitet werden.

Hinweis: Bei \wetterauskunft handelt es sich nicht um eine physikalische Pfadangabe. Wir nennen diesen Teil Path-Parameter.

In unserem konkreten Beispiel übergeben wir dem Service wetterauskunft, der den Parameter Stadt erwartet das Argument koblenz.

Auf diese Anfrage könnte uns der Server beispielsweise eine Antwort von folgender Form liefern.

{
    "Stadt": "Koblenz",
    "Wetter": "Regen",
    "Temperatur": "22/23",    
}

Ein Geständnis:

Das Modell des RESTful Web-Service stammt aus dem Lehrbuch und wie du weißt sind Modelle lediglich eine Annäherung an die Wirklichkeit. Nach strenger Lehrbuchmeinung ist obige URL nicht vollständig REST basiert, da \wetterauskunft?stadt=koblenz Rückschlüsse auf eine Aktion zulässt.

Möchten wir eine RESTful URL haben, die nach Lehrbuchmeinung als vollständig RESTful akzeptiert wird, dann müssen wir auch das Argument stadt als Path-Parameter übergeben. Also

http:\\www.wetterfrosch.com\wetterauskunft\stadt\koblenz

Für mich als Praktiker geht hierbei allerdings ein großer Teil Klarheit verloren. Wenn du anderer Meinung bist, dann hinterlass mir doch bitte einen Kommentar :-).

In der Praxis hat es sich eingebürgert QueryParameter als Filterwerte zu verwenden.

RESTful Cosumers und Producers

Sowohl der Client als auch der Server können sowohl Daten Empfangen als auch senden.

Einen Teilnehmer, der Daten sendet nennt man Producer und ein Teilnehmer, der Daten empfängt heißt Consumer.

Wie teilen wir einem Teilnehmer mit, ob er die Rolle eines Producers oder eines Consumers übernehmen soll?

Für diesen Zweck verwenden wir die Abfragemethoden GET, POST, PUT etc. des http Protokolls.

In unserem Wetterauskunftsdienst sind die Rollen klar verteilt.

Unser Client erstellt die Anfrage für die Wetterdaten von Koblenz an den Server und erwartet von diesem eine Antwort.

Um dem Server mitzuteilen, dass wir eine Rückgabe von Daten erwarten verwenden wir die GET Methode.

Der Client übernimmt in diesem Szenario die Rolle des Consumers (empfängt Wetterdaten) und der Server die Rolle des Producers (sendet Wetterdaten).

Schauen wir uns zur Verdeutlichung ein weiteres Beispiel an. Und zwar die Übermittlung des Inhalts eines Adressformulars an den Server.

In diesem Szenario sendet der Client einen POST request an den Server, der die im Adressformular eingegebenen Daten überträgt.

Jetzt tritt also der Client als Producer und der Server als Consumer auf.

Bei einem RESTful Web-Service geben wir also mit Hilfe der URL an, auf welchen vom Server angebotenen Service wir zugreifen und mit Hilfe der http Abfragemethoden legen wir fest, ob der Client lesend oder schreibend auf den Server zugreifen soll.

Ressource URL’s und Collection URL’s

Bei RESTful Web-Services ist also die Struktur der URL entscheidend.

Daher wollen wir uns im folgenden anhand eines Beispiels ansehen wie REST konforme URL’s aussehen.

Wie könnten wir beispielsweise einen Reiseanbieter, nennen wir ihn Reisefan, mit Hilfe einer REST API realisieren?

Hier stellt sich zunächst die Frage, welche Services wir hierfür benötigen.

Als erstes möchten wir sicher eine Möglichkeit haben sämtliche Angebote abzufragen. Eine für diesen Service passende URL hätte die Form.

http://www.reisefan.de/reiseangebote

Mit Hilfe eines GET http request könnten wir hierüber einen Service ansprechen, der uns eine Liste sämtlicher Reiseangebote zurückliefert.

Da ein üblicher Reiseanbieter ungefähr 467925322 Angebote in seiner Datenbank hat, liefert uns ein GET Request eine Menge von Angeboten zurück.

Eine URL, hinter der ein Service liegt, der mehr als ein Datensatz zurückliefert nennt man Collection URL.

Da die Darstellung der 467925322 Angebote in einer App leicht unübersichtlich werden kann, gibt es eine Technik, die man Pagination nennt, mit der man die Menge der Daten auf eine Teilmenge einschränken kann.

Pagination realisieren wir mit Hilfe von QueryParametern.

Interessieren wir uns beispielsweise für die Angebote 30-50, so können wir das in der URL wie folgt ausdrücken.

http://www.reisefan.de/reiseangebote?von=30&bis=50

So weit so gut! Aber in vielen Fällen sind wir gar nicht an einer Liste mit allen Reiseangeboten interessiert. Sondern wir interessieren uns vielmehr für die Angebote zu einem bestimmten Ziel.

Hierfür ist es sinnvoll die URL zu verfeinern. Nehmen wir an wir wollen uns alle Angebote zu dem Reiseziel Mallorca anzeigen lassen, dann hätte eine hierfür geeignete URL folgendes aussehen.

http://www.reisefan.de/reiseangebote/mallorca

Da es zu dem Reiseziel Mallorca ebenfalls mehr als ein Angebot gibt, handelt es sich auch hier um eine Collection URL.

Spielen wir das Spielchen noch ein wenig weiter. Jetzt möchten wir ein Angebot zu dem Hotel Hotel-Paradise. Dazu verfeinern wir unser URL noch um eine weitere Ebene.

http://www.reisefan.de/reiseangebote/mallorca/hotelparadise

Das Verfeinern dieser URL macht keinen Sinn, denn ein GET auf diese URL liefert uns genau ein Angebot.

Eine URL, die keine Menge sondern einen einzigen Datensatz zurück liefert nennen wir Resource URL.

Der Unterschied zwischen Collection und Resource URL lässt sich vergleichen mit dem Unterschied eines Ordners und einer Datei in einem Dateisystem.

Die Collection URL’s entsprechen hierbei den Ordnern und die Resource URL’s den in diesen gespeicherten Dateien.

Warum ist die Unterscheidung zwischen Collection und Resource URL wichtig?

Das Beachten dieses Unterschieds ist besonders bei der Anwendung der http Abfragemethoden wichtig.

So hat beispielsweise die Anwendung der Abfrage Methode DELETE auf die URL http://www.reisefan.de/reiseangebote katastrophale Auswirkungen, da wir hiermit sämtliche Reiseangebote aus der Datenbank löschen würden.

Oder im Fall, dass wir mit Hilfe der POST Methode eine neue Resource anlegen möchten, können wir uns nicht auf eine bereits vorhandene Resource beziehen, sondern müssen die Methode auf die Collection URL anwenden, in der wir die neue Resource erzeugen möchten.

Was ist HATEOS?

Eine Frage bleibt noch offen.

Wie kann man von einem Service zu einem anderen Service navigieren?

Bezogen auf unser Beispiel von oben stellt sich also die Frage: Wie gelangt man vom dem Service hinter der URL http://www.reisefan.de/reiseangebote zu dem Service mit der URL http://www.reisefan.de/reiseangebote/mallorca.

Genau für diesen Zweck gibt es das sogenannte HATEOS-Prinzip.

Hierbei ist HATEOS die Abkürzung für Hypermedia As The Engine Of Application State. Hell Yeah! Starke Worte! 🙂

Was bedeutet das?

HATEOS ist eine Verallgemeinerung von Hyperlinks, die wir von Webseiten kennen.

Um von Webseite A zu Webseite B zu kommen klicken wir auf Webseite A auf einen Link, der auf Webseite B verweist.

Und genau so funktioniert auch das HATEOS Prinzip.

Einziger Unterschied ist, dass wir bei einem Web-Service keinen Link zum anklicken haben.

Stattdessen befindet sich bei HATEOS der Link in den Daten der Server Antwort.

In der Serverantwort auf die Anfrage http://www.reisefan.de/reiseangebote befindet sich also ein Verweis auf die Resource http://www.reisefan.de/reiseangebote/mallorca.

Der Zugriff auf diese Resource liefert wiederum eine Antwort, die einen Link auf eine Resource URL wie beispielsweise http://www.reisefan.de/reiseangebote/mallorca /hotelParadise enthält.

Dieser Link wird in den Nutzdaten der Server-Antwort mit Hilfe des rel Tags gekennzeichnet.

Implementierung von RESTful Web-Services

Okay, ich weiß was du denkst. Du fragst dich sicher: „Gut, aber wie implementiere ich nun einen RESTful Web-Service?“.

Bei RESTful Web-Sservices handelt es sich lediglich um ein Konzept und sobald du das verstanden hast, ist die konkrete Implementierung ein leichter Schritt.

Da RESTful Web-Services außerdem eng verwand mit dem http Protokoll sind und dieses nicht von einer bestimmten Technologie abhängt, gibt es viele unterschiedliche Implementierungswege.

Nahezu für jede Programmiersprache existieren Programmbibliotheken, mit denen sich RESTful Web-Services implementieren lassen.

Für JAVA empfehle ich dir die Implementierung mit Hilfe von JAX-RS. JAX-RS ist eine Beschreibung wie RESTful Web-Services in JAVA zu implementieren sind.

Diese Beschreibung wurde in der JAVA Programm-Bibliothek Jersey umgesetzt, die du kostenlos verwenden kannst um deine eigenen RESTful Web-Services zu implementieren.

Fazit: RESTful Web-Services bieten die Möglichkeit Services, die ein zentraler Server im Web zur Verfügung stellt anzusprechen. Hierbei wird der anzusprechende Dienst über die Struktur der URL identifiziert. Mit Hilfe der http Abfragemethoden können wir festlegen, ob wir Daten anfordern oder übertragen wollen. Mit Hilfe des HAETOS Prinzips ist es außerdem möglich eine Anfrage von einem Dienst zu einem anderen zu delegieren.

Ich freue mich auf deine Fragen in den Kommentaren!

Hat dir der Artikel gefallen? Dann folge uns doch am besten gleich auf Facebook!