RESTful Webservices (1): Was ist das überhaupt?
Einleitung
Auf den ersten Blick besteht das WWW nur aus den Komponenten, die ein menschlicher Benutzer auch wahrnehmen kann – die Webseiten und -applikationen, die beispielsweise über den Browser aufgerufen werden können. Tatsächlich aber greifen über diese Infrastruktur nicht nur menschliche Benutzer auf Inhalte zu, sondern es gibt auch „maschinelle“ Benutzer, also beispielsweise andere Anwendungen, die auf Daten aus dem Internet zugreifen. Ein Betreiber kann somit einen bestimmten Dienst im Internet anderen Anwendungen zur Verfügung stellen – diese Dienste werden Webservices genannt. Ein ganz einfaches Beispiel ist etwa Twitter: über einen entsprechenden Webservice können beliebige Anwendungen – vorherige Authorisierung vorausgesetzt – im Namen eines Benutzers Tweets auslesen oder schreiben).
Anfang des letzten Jahrzehnts war das Protokoll der Wahl für solche Webservices das Simple Object Access Protocol – kurz SOAP. Durch die Verwendung von SOAP konnte ein Client die Methoden eines serverseitigen Objekts aufrufen – das Ganze funktionierte dabei über recht komplexe XML-Nachrichten, die über das HTTP-Protokoll ausgetauscht wurden. Die Kombination aus XML und HTTP machte das ganze Protokoll programmiersprachen– und plattformunabhängig; somit konnte beispielsweise ein in C++ geschriebener Client Methoden von serverseitigen Java-Objekten aufrufen – insgesamt also eigentlich eine recht praktische Sache.
Nach einiger Zeit fielen jedoch die Schwächen von SOAP auf: die komplizierten XML-Nachrichten hatten einen recht großen Overhead (viele Metadaten, wenig Nutzdaten), außerdem war das Zusammen- und Auseinanderbauen der XML-Nachrichten rechenintensiv. Hinzu kam, dass mittlerweile auch die großen Softwarehersteller SOAP für sich entdeckt hatten und den anfänglich (relativ) unkomplizierten Standard um zahlreiche weitere Sub-Standards ergänzt hatten (und natürlich unterstützte kaum ein Hersteller die Standards der anderen Hersteller, was die Sache noch weiter verkomplizierte). Mittlerweile gibt es mehrere hundert dieser sogenannten „WS-*“-Standards, und einen richtigen Überblick darüber hat eigentlich niemand mehr.
REST-Architekturen und ihre Grundprinzipien
„Das muss doch auch irgendwie einfacher gehen“, fragten sich die Webservice-Entwickler irgendwann – und fanden die Antwort im REST-Architekturstil (kurz für Representational State Transfer). Der Begriff wurde im Jahr 2000 von Roy Fielding geprägt. Prinzipiell ist der Architekturstil selbst unabhängig von irgendwelchen konkreten Protokollen – in der Regel wird zur Implementierung solcher Architekturen allerdings das altbekannte HTTP-Protokoll verwendet.
Grundsätzlich dreht sich in einer REST-Architektur alles um Ressourcen. Um beim Twitter-Beispiel zu bleiben, könnte beispielsweise jeder Benutzer und sogar jeder einzelne Tweet als eigene Ressource betrachtet werden). Diese Ressourcen sollten laut Fielding folgende Anforderungen erfüllen:
REST und HTTP
Zur Umsetzung von solchen REST-Webservices wird in aller Regel das HTTP-Protokoll verwendet. Gründe dafür gibt es viele: Einerseits ist das Protokoll etabliert (schließlich basiert ja das gesamte WWW darauf), dennoch vergleichsweise einfach aufgebaut (der genaue Aufbau des Protokolls ist in RFC 2616 definiert) und zu guter Letzt auch in so gut wie jeder Firewall offen.
Der HTTP-Standard definiert einen ganzen Satz an Operationen, mit denen auf Ressourcen zugegriffen werden kann. Die Methoden GET und POST werden auch von jedem Browser verwendet, wenn Internetseiten aufgerufen, bzw. Formulare abgeschickt werden. Daneben gibt es aber auch noch einen ganzen Satz weiterer Operationen, die von den meisten Browsern nicht genutzt werden:
- GET dient dazu, lesend auf Ressourcen zuzugreifen. Per Definition darf eine GET-Anfrage nicht dazu führen, dass Daten auf dem Server verändert werden.
- Mit einem POST-Request können neue Ressourcen erstellt werden, deren URI noch nicht bekannt ist. Per POST-Request an könnte also beispielsweise ein neuer Kunde mit automatisch vergebener Kundennummer (und URI) erstellt werden.
- Ein PUT-Request wird verwendet, um Ressourcen zu erstellen oder zu bearbeiten, deren URI bereits bekannt ist. Ein PUT-Request an sollte demnach also einen Kunden mit der Kundennummer 123456 anlegen, falls er nicht existiert, oder ansonsten bearbeiten.
- Mit einem DELETE-Request können Ressourcen gelöscht werden.
Ein kleines Beispiel
Stellen wir uns einen fiktiven Webservice vor, der Zugriff auf eine Produkt-Datenbank bietet. Der Einstiegspunkt für den Webservice soll die URI sein. Ein GET-Request an diese URI sollte demnach also eine Liste aller Produkte zurückliefern:
Request:
GET /products HTTP/1.0
Accept: application/jsonResponse:
HTTP/1.0 200 OK
Content-Type: application/json
Content-Length: 1234
[ { uri: "http://ws.mydomain.tld/products/1000",
name: "Gartenstuhl",
price: 24.99 },
{ uri: "http://ws.mydomain.tld/products/1001",
name: "Sonnenschirm",
price: 49.99 } ]Im obigen Beispiel wird zudem noch deutlich, dass der Webservice Client über den Accept-Header mitteilen kann, in welchem Format er gerne eine Antwort erhalten würde (der Server muss diesen Header dann natürlich entsprechend auswerten und das angeforderte Format auch unterstützen). Alternativ könnte man zum Beispiel auch einen Accept: text/xml-Header mitschicken, und der Server würde dieselbe Produktliste als XML zurückschicken.
Durch einen POST-Request an dieselbe URL könnte dann ein neuer Artikel erstellt werden:
Request
POST /products HTTP/1.0
Content-Type: application/json
Content-Length: 38
{ name: "Sandkasten",
price: 89.99 }Response
HTTP/1.0 201 Created
Location: Interessant ist hier vor allem, in welchem Format die Daten zum Server geschickt werden. Schickt man ein Formular im Browser ab, so kodiert dieser die gesendeten Daten in URL-Codierung (der Sandkasten-Artikel aus dem letzten Beispiel sähe dann beispielsweise so aus: &name=Sandkasten&price=89.99). In einer REST-Architektur wäre dies genauso möglich, allerdings müsste der Client dann auch einen Content-Type: application/x-www-form-urlencoded-Header mitschicken.
Außerdem auffällig ist hier, dass der Server in diesem Fall nicht mit dem üblichen 200 OK-Status antwortet, sondern mit 201 Created. Außerdem enthält die Antwort einen Header, der die URI der neu erstellten Ressource enthält.
Weitere Funktionen von HTTP
Dadurch, dass für einen Webservice einfaches HTTP verwendet wird, ergeben sich noch reichlich weitere interessante Möglichkeiten. Da HTTP beispielsweise einen ganzen Satz an Caching-Headern definiert, kann ein REST-Webservice beispielsweise ganz genau vorschreiben, unter welchen Umständen und für welchen Zeitraum ein Client die Antworten zwischenspeichern kann. Die Cache-Control-Header ermöglichen in Kombination mit der eindeutigen Adressierbarkeit auch ein Caching der Antworten über einen Reverse Proxy (wie beispielsweise Varnish oder Squid).
Zugriffssicherheit lässt sich in einem RESTful Webservice am einfachsten über die ganz normale HTTP-Authentifizierung erreichen. Hierbei schickt der Client bei jeder Anfrage einen Authentication-Header mit, in welchem ein Benutzername und ein Passwort codiert sind. Die HTTP-Authentifizierung selbst setzt keine Benutzersitzung voraus, da einfach ganz naiv bei jeder Anfrage die kompletten Authentifizierungsdaten mitgeschickt werden. Damit das Ganze keiner mitlesen kann, kann die komplette HTTP-Kommunikation auf Transportebene per SSL verschlüsselt werden.
Ausblick
Ich hoffe, ich konnte euch einen kurzen Einblick in die Welt der RESTful Webservices geben? Wenn Ihr Fragen und Anregungen zum Artikel habt, freue ich mich über Eure Kommentare! :) In einem späteren Artikel werde ich noch einmal genauer darauf eingehen, wie Ihr REST-Webservices ganz einfach mit PHP-Frameworks wie beispielsweise TYPO3 Flow umsetzen könnt.
Diesen Artikel findet ihr hier: RESTful Webservices (2).
Kommentare
danke für den Artikel
Sehr guter Überblick! Richtig gut beschrieben; auch für Personen, die wenig damit zu tun haben.
vielen Dank für deinen Kommentar.
Es freut uns zu hören, dass wir weiterhelfen konnten. ;)
Viele Grüße
Kristina
RFC 2616 ist ersetzt durch HTTP V2.
Danke für die sehr gut nachvollziehbaren Erklärungen. Besonders gut gefallen mir die Beispiele.
Hallo Sabine,
vielen Dank für dein Lob!
Liebe Grüße
Kristina
Tolle Zusammenfassung. Genau auf dem Punkt.
Richtig toller Artikel, dankeschön!
In meiner Masterarbeit wird ein RESTfull-Webservice eines der Themen sein. Also heißt es, sich erst einmal einarbeiten. Dies war bisher einer der interessantesten Artikel, die ich zu dem Thema gelesen habe. Ich denke, dass ich das Grundsätzliche jetzt verstanden haben – jetzt muss ich das nur noch in Java umsetzen.
Sehr gut zusammengefasst. Bring es auf den Punkt
Tratitu, das „ful“ ist – meines Wissens nach, daher nicht zwingend richtig – nur die typisch Englische Erweiterung. Keine Ahnung wie das in der Fachsprache heißt, aber es zeigt an, dass es „mit“ dem Wort davor ist. Zum Beispiel: das englische Wort care.
care heißt sorgen.
careful heißt sorgam, sich sorgen… wie in „be careful“
und careless zum Beispiel heißt rücksichtslos, also ohne sich zur sorgen.
Wenn der Webservice also RESTful ist, heißt das denke ich einfach nur, dass er REST unterstützt. Wäre er RESTless, würde er es nicht unterstützen.
So ist meine Interpretation ;)
Danke für den Artikel. Mir ist aber nicht klar, was nun das „ful“ in
RESTful bedeuten soll. Könnte das noch jemand beantworten?
Super!! Sehr Informativ – Danke!!!
Einfach und verständlich.
Bin neu hier und habe nach dem Artikel Lust auf mehr bekommen.
super, sehr gut erklaert und auch die Begriffe wie stateful etc. und wie man genau get,post,put verwendet. Vielen Dank, hab nun in einem Artikel all das gefunden wofuer ich sonst stundenlang googeln muss
Auch von mir ein Kompliment. Super erklärt!
Vielen Dank für diesen sehr gut verständlichen Artikel!
Vielleicht könntest du am Ende noch den Link zum zweiten Artikel reinsetzen, hab nämlich grad etwas suchen müssen, bis ich ihn hatte.
Danke für den Hinweis. Der Link ist nun unten im Artikel zu finden.
Viele Grüße
Annika vom Mittwald Social Media Team
Damit hast du mir sehr weitergeholfen. Vielen Dank!
Sehr gut erklärt, Vielen Dank
3 Wochen Vorlesung keinen blassen Schimmer gehabt was der Prof. da erzählt – 10 min. diesen Artikel gelesen und das ganze verstanden. TOP Artikel. Danke! :)
Ganz hervorragend, das Wesentliche auf den Punkt bringend, erklärt!
Ein wirklich sehr interessanter und sehr gut ausgeführter Artikel ;) Danke!!