O'Reilly logo

Rails Kochbuch by Rob Orsini

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

First
|
213
Max.
Linie
Max.
Linie
Kapitel 6
KAPITEL 6
REST-orientierte Entwicklung
6.0 Einführung
Von Ryan Daigle
Kurz vor der ersten Rails-Konferenz begann David Heinemeier Hansson seine Arbeit an
einem grundlegend neuen Ansatz für den Entwurf und die Entwicklung von Rails-Anwen-
dungen. Sein Vortrag auf dieser Konferenz hatte den Titel »Resources on Rails«. Darin
stellte er die Idee einer ressourcenorientierten Rails-Entwicklung und einer Software-
Architektur namens Representational State Transfer, kurz REST, vor.
REST ist eine Architektur, die ursprünglich von Roy Fielding in seiner Doktorarbeit
(http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm) vorgestellt wurde. Sie erlaubt
den Aufbau vollständiger und erweiterbarer Web-Dienste und -Anwendungen, die auf
einer kleinen Menge grundlegender Operationen aufbauen. Diese Operationen sind die
normalen HTTP-Request-Methoden (GET, POST, PUT, DELETE), von denen Sie mög-
licherweise nur mit GET und POST vertraut sind. Die Web-Entwicklung hat die voll-
ständige HTTP-Spezifikation lange ignoriert und den GET- und POST-Methoden eine
große Verantwortung auferlegt: Sie mussten die ganze Last des Anforderns und Sendens
der Daten von und zu dynamischen Web-Anwendungen schultern. Aber diese Request-
Methoden, diese Verben, bilden den Kern einer sehr einfachen, aber leistungsstarken
Entwurfsmethodik.
REST ist eine Konversation
Bei REST geht es darum, HTTP-Requests in eine natürliche, der menschlichen Sprache
ähnliche Struktur mit Verben und Nomen zu bringen. Die Verben einer REST-Konversa-
tion sind die vorhin erwähnten Request-Methoden, während die Nomen URIs sind, ein-
deutige Identifier für eine über das Web zugängliche Ressource. Der Begriff »Ressource«
beschreibt dabei alles, was über das Web zugänglich ist: Denken Sie dabei an ein Buch auf
Amazon oder einen Artikel auf eBay. Deren URIs sind Identifier für diese realen Elemente,
diese Ressourcen.
00____RailsKochbuch.book Seite 213 Dienstag, 3. Juli 2007 8:13 08
Max.
Linie
Max.
Linie
214
|
Kapitel 6: REST-orientierte Entwicklung
Links
Zu häufig ignorieren wir die grundlegende Satzstruktur, weil wir vergessen, dass Verben
bestimmte Aktionen anzeigen, und stattdessen den URI nutzen, um unsere Wünsche aus-
zudrücken. Was das aus technischer Sicht bedeutet, zeigt dieser Request:
GET "/books/destroy/1"
überlädt den URI. Ein URI sollte einen Zeiger auf eine Ressource darstellen, während die-
ser Request uns zwingt, sowohl die Ressource (ein bestimmtes Buch) als auch die für diese
Ressource vorgesehene Aktion (destroy) anzugeben. Unser Ziel besteht darin, die Integri-
tät von URIs als reine Nomen zu wahren, indem wir stattdessen den folgenden Request
verwenden:
DELETE "/books/1"
Hier haben wir einen URI, der nur eine einzige Sache angibt: die Lage eines Buches. Die
Request-Methode DELETE gibt die Aktion an, die mit diesem Buch durchzuführen ist.
Häufig hat es unvorhergesehene Konsequenzen, wenn die Request-Methoden nicht rich-
tig verwendet werden, d.h., wenn GETs genutzt werden, um Ressourcen zu löschen oder
zu modifizieren. Eine der bekanntesten Konsequenzen tritt ein, wenn Browser Seiten im
Voraus laden (Page-fetching), die auf der aktuellen Seite des Benutzers verlinkt sind. Sol-
che Tools finden alle mit GET angeforderten Ressourcen (Links) einer Seite und fordern
sie an, in der Annahme, dass der Benutzer sie im Verlauf der Session einmal nutzt. Wenn
Links zum Löschen eines Benutzers aber blind mittels GET konstruiert werden, dann ruft
ein solcher Prefetch-Mechanismus die destruktiven oder modifizierenden Requests ab.
Indem man sich strikt an REST hält und GETs nur für idempotente Requests verwendet,
kann man solche ungewollt destruktiven Situationen vermeiden.
REST ist Design
An diesem Punkt könnten Sie sich fragen, ob es bei REST nur um die Semantik von HTTP
geht. Nein, bei REST geht es nicht nur darum, die Grammatik von HTTP richtig anzuwen-
den, sondern es geht auch darum, das bewusst Kurze und Präzise der HTTP-Verben im
Entwurf Ihrer Anwendungen nachzuahmen.
Bei gutem Design geht es nicht um die Schwierigkeiten bei der Lösung einfacher Aufga-
ben. Es geht um die Vereinfachung komplexer Aufgaben, also darum, Probleme auf die
wirklich grundlegenden Dinge zu reduzieren, sodass sie richtig analysiert, richtig reprä-
sentiert und richtig adressiert werden können. REST stellt uns ein Framework für einen
einfachen, aber erweiterbaren Anwendungsentwurf zur Verfügung, indem es vorgibt, wel-
che Aktionen eine Anwendung für eine Ressource vornehmen kann:
GET
liest eine Ressource.
POST
erzeugt eine Ressource.
00____RailsKochbuch.book Seite 214 Dienstag, 3. Juli 2007 8:13 08

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required