RESTful Webservices (1): Was ist das überhaupt?

Einer der Begriffe, die Entwickler in letzter Zeit immer wieder zu hören bekommen, ist der Begriff des RESTful Webservices. Zahlreiche große Internet-Unternehmen, wie z. B. Twitter, Facebook oder Google bieten eigene REST-Schnittstellen zu ihren Diensten an. Was hat es also mit den Begriffen REST, RESTful HTTP und REST-Webservices auf sich und wie können Entwickler solche Webservices mit den üblichen Hausmitteln (wie beispielsweise TYPO3 Flow) selbst implementieren?

Einleitung

Agenturhoster testen
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 HTTP 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.

Grundprinzipien von REST-Architekturen

„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:

1
Adressierbarkeit: Jede Ressource muss über einen eindeutigen Unique Resource Identifier (kurz URI) identifiziert werden können. Ein Kunde mit der Kundennummer 123456 könnte also zum Beispiel über die URI adressiert werden.
2
Zustandslosigkeit: Die Kommunikation der Teilnehmer untereinander ist zustandslos. Dies bedeutet, dass keine Benutzersitzungen (etwa in Form von Sessions und Cookies) existieren, sondern bei jeder Anfrage alle notwendigen Informationen wieder neu mitgeschickt werden müssen.

Durch die Zustandslosigkeit sind REST-Services sehr einfach skalierbar; da keine Sitzungen existieren, ist es im Grunde egal, wenn mehrere Anfragen eines Clients auf verschiedene Server verteilt werden.

3
Einheitliche Schnittstelle: Jede Ressource muss über einen einheitlichen Satz von Standardmethoden zugegriffen werden können. Beispiele für solche Methoden sind die Standard-HTTP-Methoden wie GET, POST, PUT, und mehr.
4
Entkopplung von Ressourcen und Repräsentation: Das bedeutet, dass verschiedene Repräsentationen einer Ressource existieren können. Ein Client kann somit etwa eine Ressource explizit beispielsweise im XML- oder JSON-Format anfordern.

REST und HTTP

Zur Umsetzung von solchen REST-Services 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:

 

 

Im obigen Beispiel wird zudem noch deutlich, dass der 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:

 

 

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 anCaching-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 Webservices ganz einfach mit PHP-Frameworks wie beispielsweise TYPO3 Flow umsetzen könnt.
Diesen Artikel findet ihr hier: RESTful Webservices (2).

 

  1. Einleitung
  2. Grundprinzipien von REST-Architekturen
  3. REST und HTTP
  4. Ein kleines Beispiel
  5. Weitere Funktionen von HTTP
  6. Ausblick

Kommentare

  1. Gravatar
    R. Meier am

    RFC 2616 ist ersetzt durch HTTP V2.

    Antworten
  2. Gravatar
    Sabine G. am

    Danke für die sehr gut nachvollziehbaren Erklärungen. Besonders gut gefallen mir die Beispiele.

    Antworten
    1. Gravatar
      Kristina Dahl am

      Hallo Sabine,

      vielen Dank für dein Lob!

      Liebe Grüße
      Kristina

      Antworten
  3. Gravatar
    John D am

    Tolle Zusammenfassung. Genau auf dem Punkt.

    Antworten
  4. Gravatar
    Laura am

    Richtig toller Artikel, dankeschön!

    Antworten
  5. Gravatar
    Christopher am

    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.

    Antworten
  6. Gravatar
    Chris am

    Sehr gut zusammengefasst. Bring es auf den Punkt

    Antworten
  7. Gravatar
    Nil am

    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 ;)

    Antworten
  8. Gravatar
    Tratitu am

    Danke für den Artikel. Mir ist aber nicht klar, was nun das „ful“ in
    RESTful bedeuten soll. Könnte das noch jemand beantworten?

    Antworten
  9. Gravatar
    Ramazan am

    Super!! Sehr Informativ – Danke!!!

    Antworten
  10. Gravatar
    Kristine am

    Einfach und verständlich.
    Bin neu hier und habe nach dem Artikel Lust auf mehr bekommen.

    Antworten
  11. Gravatar
    Fraenzi B. am

    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

    Antworten
  12. Gravatar
    Patrick M. am

    Auch von mir ein Kompliment. Super erklärt!

    Antworten
  13. Gravatar
    Floh am

    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.

    Antworten
    1. Gravatar
      Annika Schwanitz am

      Danke für den Hinweis. Der Link ist nun unten im Artikel zu finden.

      Viele Grüße
      Annika vom Mittwald Social Media Team

      Antworten
  14. Gravatar
    Sven am

    Damit hast du mir sehr weitergeholfen. Vielen Dank!

    Antworten
  15. Gravatar
    Abdullah am

    Sehr gut erklärt, Vielen Dank

    Antworten
  16. Gravatar
    AD am

    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! :)

    Antworten
  17. Gravatar
    Peter am

    Ganz hervorragend, das Wesentliche auf den Punkt bringend, erklärt!

    Antworten
  18. Gravatar
    Manuel am

    Ein wirklich sehr interessanter und sehr gut ausgeführter Artikel ;) Danke!!

    Antworten

Kommentar hinzufügen