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.

6 Gedanken zu “Ein guter Architekturstil: REST

  1. … soll man daraus schliessen das man keine Sessions benutzen soll und jeweils immer alle daten über Cookies beim client speichern? ist das sicherheitstechnisch nicht fraglich vorallem wenn nicht immer SSL verschlüsselung gebraucht wird?

  2. Ist der Punkt „Keine HTML-Endung“, denn“, denn „der Client entscheided was er will“, nicht widersprüchlich mit dem Konzept der sprechenden URLs?

    Wenn die gleiche URL einmal ein HTML Dokument schickt und mit nem anderen „Client“ z.B. die PDF Version davon, ist das doch genau so irritierend, wie wenn verschiedene Sprachversionen unter derselben URL ausgeliefert werden.

  3. @Valentin.

    Als ich mich eingelesen habe, fragte ich mich dieselbe Sache ziemlich früh… Ich kann doch wohl kein eBanking mit Query-Parametern machen. Gefunden habe ich dann einen Post von Fielding, welcher mir die Cookie-Variante offen liess (http://groups.yahoo.com/group/rest-discuss/message/3583).

    Als ich damit noch nicht alle meine Bedenken ausgeräumt habe, schrieb ich in den Post „Natürlich nur bei Anwendungen, wo dies auch so funktioniert…“. Das sind aber immerhin einige ;-)

  4. @ Chregu

    Teils auf Deiner Seite und Teils hin- und hergerissen. Ich habe mal geschrieben, wie ich Roy verstsanden habe… er weiss so Sachen ja. Vielleicht habe ich auch falsch verstanden.

    Bei HTML und PDF ist das eher zu Gunsten von Auszeichen. Wie ist es aber bei HTML 3.x, 4.x und XHTML? Vielleicht sind die Client heute auch doof gemacht. Im Accept Header könnte ich die Media Types ja eigentlich klar vorgeben… das UI des Clients gibt es aber nicht wirklich her.

    Es gibt je immer noch den Unterschied zwischen „Ressource“ und „Repräsentation“. Aber so wie ich interpretiere darf ich nicht redirecten auf eine spezifische URL.

    Als: Grundsätzllich ist „let the user decide“ ja doch das Beste… aber wenn es halt keinen Knopf hat ;-) Da ist Roy möglicherweise der heutigen Realität ein bisschen voraus.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>