t3n 7

Teil 1: Theorie einer neuen Web-Architektur in Ruby On Rails: REST in Rails

Seite 2 / 5

Saubere URLs

Eine Web-Applikation (oder allgemeiner: ein Web-Service) wird nach außen hin durch URLs repräsentiert. Dafür gibt es unendlich viele Implementierungs-Möglichkeiten. Diese Vielfalt bringt den Nachteil, dass jeder Service für Außenstehende erst einmal wieder unbekannt und unverständlich ist. Dabei sind Außenstehende nicht nur fremde User und Entwickler, die den Service einbinden oder sich einarbeiten müssen. Auch andere Services wie Robots oder Clients, denen erst einmal beigebracht werden muss, welche Parameter im Service was bewirken, profitieren von Standards.

Hier einige Beispiele für einen fiktiven Adressen-Service mit vier (von unendlich vielen weiteren) denkbaren URLs, die alle das Gleiche bewirken – eine Adresse löschen:

Aktion Beispiel-URL
GET-Call http://beispiel.de/addresses.php?id=123&do=delete
POST-Call http://beispiel.de/addresses.php mit CGI-Stil-Bodyid=123&do=delete
POST-Call http://beispiel.de/addressAdmin/command=delete mit CGI-Stil-Bodyid=123
POST-Call http://beispiel.de/addresses/destroy/123
DELETE-Call http://beispiel.de/addresses/123

Die erste URL, die per GET versendet wird, verletzt eine goldene Regel: GET-Requests sollen keine Ressourcen verändern – sie sind nur für Abfragen zuständig. Die URL, per GET zum Beispiel auf einem handelsüblichen Link, löscht aber etwas, nämlich die Adresse mit der ID 123. Wird der Link nun als Bookmark angelegt und erneut aufgerufen oder durch einen Suchmaschinen-Crawler aktiviert, wird die Aktion abermals aufgerufen, womöglich auf einem anderen Datensatz, der jetzt die ID 123 hat. Das ist sicherlich nicht im Sinne des Erfinders und somit ist diese Methode disqualifiziert. Die zweite, dritte und vierte Variante kommen ohne den Fehler aus. Dennoch gibt es auch hier ein Problem: Ressource und Aktion werden vermischt. Bei einer normalen CRUD-Aktion (Create Read Update Delete) ist es nicht nötig, die Aktion mit in die URL zu packen. Praktisch bedeutet das nämlich, dass jede Aktion unnötigerweise wieder eine unterschiedliche URL bekommt. Ein Vergleich zwischen klassischen Rails-URLs und RESTful-Rails-URLs zeigt den Unterschied:

Aktion URL ohne REST URL mit REST
show /addresses/show/123 /addresses/123
delete /addresses/destroy/123 /addresses/123
update /addresses/update/123 /addresses/123
create /addresses/create /addresse

Da bei REST Ressource und Aktion voneinander getrennt bleiben, gilt hier für eine Ressource immer die gleiche URL – egal, welche Aktion mit ihr durchgeführt werden soll. Zwei Aspekte ermöglichen das in REST: die Wiederentdeckung von HTTP und das Denken in Ressourcen.

Bitte beachte unsere Community-Richtlinien

Schreib den ersten Kommentar!

Du musst angemeldet sein, um einen Kommentar schreiben zu können.

Jetzt anmelden

Hey du! Schön, dass du hier bist. 😊

Bitte schalte deinen Adblocker für t3n.de aus, um diesen Artikel zu lesen.

Wir sind ein unabhängiger Publisher mit einem Team bestehend aus 65 fantastischen Menschen, aber ohne riesigen Konzern im Rücken. Banner und ähnliche Werbemittel sind für unsere Finanzierung sehr wichtig.

Danke für deine Unterstützung.

Digitales High Five,
Stephan Dörner (Chefredakteur t3n.de) & das gesamte t3n-Team

Anleitung zur Deaktivierung