Ein guter Architekturstil: REST

Als der Autor André Kaminski im Alter von 63 Jahren mit Nächstes Jahr in Jerusalem seinen ersten Bestseller geschrieben hatte, fragte ein eifriger Journalist, weshalb es keinen früheren bekannten Werke von ihm gibt. Die Antwort: «Zuerst müssen sie lesen, dann schreiben…».
Das gilt wahrscheinlich auch für Roy T. Fielding, Chief Scientist bei Day und Miterfinder der zwei wohl wichtigsten Internet-Standards: HTTP (RFC 2616, RFC 2145, RFC 2068, RFC 1945) und URI (RFC 2396, RFC 1808) und noch einige Papiere und Software mehr. Er schrieb mit 35 Jahren seine Dissertation mit dem Titel: Architectural Styles and the Design of Network-based Software Architectures. Das zentrale Konzept drin ist REST (Representational State Transfer) und das ist gut zu wissen.
Stark vereinfach geht es um gute Adressierung im Internet und zwar nicht als neuer Standard, aber als korrekte Anwendung der vorhandenen Standards wie HTTP, URL, MIME Types u.a. Es geht etwa so:
1. Eine Ressource ist ein logisches Ziel welches immer gleich ist. Sie ist einfach verständlich und memorisierbar beschrieben. Beispielsweise http://www.namics.com/leistungen/produkte
2. Die Repräsentation ist die konkrete (physische) Antwort auf die Anfrage nach einer Ressource. Im Bezug auf das Beispiel oben ändern sich die namics Produkte über Zeit oder es gibt möglicherweise verschiedene Instanzen dafür (Sprachen, Clientcode u.a.). Der Pfad zur Resource bleibt gleich.
Was ist wichtig bei einer Ressource resp. dem Pfad dorthin?
a) Eine Ressource ist für Menschen (d.h. sprechend) und technologienbeutral beschrieben. Also ohne PHP -Endung, da die Implementierung von PHP auf APSX ändern könnte (oder was auch immer). Es muss stabil bleiben.
b) Keine HTML-Endung, da je nachdem wer/wie anfrägt, soll nicht HTML aber bspw. XML oder PDF geliefert werden. Für den Entscheid was ausgeliefert werden soll, gibt es im HTTP Request Header Feld mit Accept* die Angabe, was bevorzugt ist. Welches Format, welche Sprache, welche Codierung etc. In einer Idealen Welt entscheidet der Client was er will und nicht die Adresse der Anfrage.
c) Die Interaktion erfolgt immer durch den Client
d) Der Aufruf soll zustandslos sein resp. der Request selbst muss alle Zustandsinformationen beinhalten (Cookie ist erlaubt, da im Request drin aber mit den Daten und nicht einer ID zu einer Serversession)
e) Caching gehört unterstützt resp. korrekt gesteuert
f) Alle Arten die interaktion erfolgt über die Standardmethodem im HTTP (GET, POST, PUT, DELETE)
g) URI als universelles Adressierungssystem
Das ist sehr theroetisch beschrieben, aber in Kurzform geht es um: Gute URL die immer funktionieren, von mir schon als sprechende oder real speaking URLs bezeichnet. Natürlich nur bei Anwendungen, wo dies auch so funktioniert… Beispiele:
>> http://www.technorati.com/search/stuker
>> http://map.search.ch/bern
>> http://tel.local.ch/zh/namics.html
>> http://www.flickr.com/photos/tags/namics/
>> http://www.bloglines.com/myblogs
>> geht aber auch für komplexere Sachen wie beispielsweise ein Yahoo-API.
Immer sehr klar was zurückkommt und immer funktionierend. Und hier für Leute die gerne lesen die Diss, ein ganzes Wiki zum Thema eine Linksammlung bei Paul Prescod und eine Mailingliste auf welcher auf Roy drauf ist.