1. Aufbau eines REST Web-Service – Teil 2

    Stefan · 02.09.08, 01:18 Uhr · Konzepte, Tutorials · Tags: ,

    Nachdem wir die grundlegenden Anforderungen des Web-Services dargestellt haben, will ich hier kurz auf REST im Allgemeinen eingehen und die Struktur unseres Web-Service aufzeigen.

    Was macht also ein RESTful Web-Service genau?

    REST nutzt vor allem die bestehende Infrastruktur des Internet. Es zeichnet ich vor allem dadurch aus, dass ein voller REST-Service das volle Spektrum der HTTP-Request-Methoden und HTTP-Header nutzt. So werden neben den beiden im Internet allseits bekannten Request-Methoden GET und POST vor allem die weiteren Standard-Methoden HEAD, PUT und DELETE genutzt. Die weiteren Methoden OPTION oder TRACE kommen in freier Wildbahn eher selten vor.

    Der Vorteil dieser Arbeitsweise von REST ist, dass ein und die selbe URI anhand der Request-Methode ganz genau weiß, was sie zu tun hat. Da XHTML 1.x (das momentan Standard ist) lediglich GET und POST als Request unterstützt müssen Browsernutzer noch einige Zeit auf HTML5 und Web-Forms2 warten, bis auch PUT und DELETE in den Request Methoden unterstützt werden. Das hindert uns aber nicht daran, unseren serverseitigen Client bereits damit umgehen zu lassen. Ein weiteres Merkmal eines REST Web-Service ist der korrekte Umgang mit HTTP-Statuscodes (wir alle kennen den Statuscode 404 für “Datei nicht gefunden”). RESTful Web-Services nutzen die bestehende Bandbreite dieser bereits von w3.org definierten Statuscodes, um dem Client den genauen Status der Anfrage bereits als programmiererisch sehr einfach zu handhabenden HTTP-Header mitzuliefern. Die umfangreiche Nutzung von HTTP Headern ist daher ein weiteres Merkmal eines REST Web-Service.

    Der große Vorteil dieser Arbeitsweise ist die Einfachheit für den späteren Nutzer des Web-Services. Jeder REST Web-Service, egal von welchem Projekt oder welcher Website, versteht unter DELETE /filename oder PUT /filename genau das gleiche! Somit entfällt eine langwierige Einarbeitung für den Entwickler in die Schnittstelle des Projektes. Der weitere Vorteil kommt mit HTML5, dass die wichtigsten vier Request-Methoden kennt. Somit kann man unter Nutzung von HTML5 Formulare auf Websites genau das machen lassen was sie eigentlich sollen, ohne über bei PHP z.B. sehr oft zu findende Hilfkonstrukte in der URI, wie ?action=delete&id=12, gehen zu müssen. Die eindeutige Adressierbarkeit des Objektes über eine klare URI (z.B. verzeichnis1/datei.html) ist daher ein sehr wichtiger Punkt in einem REST Web-Service.

    Soviel erst einmal zur Grundlegenden Arbeitsweise eines REST Web-Services. Eigentlich ganz trivial das Ganze. Wer sich intensiver mit dem Thema auseinander setzen möchte, dem sei das Buch RESTful Web Services aus dem O’Reilly Verlag ans Herz gelegt!

    Kommen wir nun zu einem praktischen Beispiel wie der Web-Service in Real-Life aussehen würde: Nehmen wir an wir haben jede Menge Inhalte, z.B. in einem Wiki gespeichert und wollen nun diese Inhalte weiteren Partnern zur Verfügung stellen, die verschiedene Inhaltsmengen anhand einer Art Suchabfrage definieren können. Das ganze könnte man mit einer Art Yahoo-Pipes vergleichen, bei dem viele Inhalte aggregiert und nach entsprechenden Sortierkriterien neu ausgegeben werden.

    Als Erstes unterteilen wir das Projekt in 2 verschiedene Ressourcen – die erste nenne ich jetzt einmal “Feed”, die andere Ressource “Artikel”. Das Prinzip ist einfach: Jedem Feed wird ein benutzerdefinieres Suchwort zugewiesen, anhand dessen eine Artikelliste generiert wird. In folgender Übersicht definiere ich die notwendigen Request Methoden und was sie machen (Benutzerauthendifizierung etc. habe ich der Übersichtlichkeit halber erst einmal unter den Tisch fallen lassen):

    Methode Pfad Beschreibung
    GET / Gibt eine Liste mit allen meinen Feeds im XML-Format zurück
    PUT /[feedname] Ein XML-String mit dem Suchwort wird an [feedname] gesandt. Ist bereits ein Feed mit [feedname] vorhanden, wird dieser Datensatz aktualisiert, wenn nicht, wird ein Feed mit dem angeforderten Namen erzeugt.
    DELETE /[feedname] Löscht den Datensatz [feedname] unwiderruflich
    GET /[feedname] Gibt eine Liste im XML-Format mit allen, dem Suchwort in [feedname] entsprechenden, Artikeln zurück. In der XML-Liste sind alle Artikel den zwei relevanten Informationen enthalten: Artikelname/Überschrift und Pfad, wo sich der Artikel befindet.
    GET /[feedname]/
    artikelname[.xml|.json|.html]
    Gibt die Detailinformationen zum Artikel wieder. Anhand der Dateiendungen die ich zusätzlich mit Anfrage, kann mein Web-Service die Artikeldetails wahlweise als XML, JSON oder HTML an den Client zurückliefern.

    Das war ganz grob (und natürlich nicht vollständig) der exemplarische Aufbau eines Web-Service. Das Ganze kann man jetzt beliebig komplex machen, wobei man immer im Hinterkopf behalten sollte, so viele Informationen wie möglich in die URI zu packen, um bestimmte Rückgabewerte eindeutig identifizieren zu können.

    In einem der nächsten Postings werde ich die Zend_Rest_Client-Klasse unter die Lupe nehmen und darlegen, weshalb diese im Standardpaket nicht vollständig für unsere Art RESTful Web-Service geeignet ist.

  2. Kommentare

    1. polyCODER » Aufbau eines REST Web-Service - Teil 3 · 07.12.08, 12:58 Uhr

      [...] Artikel: Aufbau eines REST Web-Service – Teil 2 Grundsätzliche Überlegungen für einen Web-Service – Teil [...]

  3. Kommentar schreiben

    XHTML: Du kannst diese Tags nutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Gehe zur polyCODER Startseite