Ansichten eines Informatikers

Ruby on Rails 2.0: restful routing

Hadmut
22.5.2008 23:18

An sich ist Ruby on Rails ja eine feine Sache. Aber jetzt haben sie wirklich einen Bock geschossen.

Ich wollte gerade eine für Rails 1.3 geschriebene Applikation auf Rails 2.0 portieren und um neue Funktionen erweitern. Und bin auf Probleme gestoßen.

Früher war alles besser. Da hatten die Rails-URLs eine einfach Struktur, nämlich /:controller/:action/:id , und das war’s. Ende. Leicht und einfach mit Funktionen wie link_to und redirect_to zu erzeugen. Und denen konnte man auch Variablen als Parameter übergeben, etwa redirect_to oder link_to.

Jetzt haben sie da etwas neues eingeführt was sich “Restful Routing” schimpft und auf einem eigentümlichen Modell von Zugriffen beruht. “REST” steht für ” Representational State Transfer”, es geht dabei darum, eine gewisse Klasse von Remote Procedure Calls auf HTTP-Requests, genauer gesagt GET, PUT, POST und DELETE abzubilden. Das kommt mir mächtig an den Haaren herbeigezogen vor. Siehe hierzu:

Selbst wenn man das implementieren wollte, warum auch immer, gibt es keinen nachvollziehbaren Grund, das an Stelle der alten Funktionen und nicht zusätzlich zu machen.

Für einen schwerwiegenden Design-Fehler halte ich dabei, daß man die URLs nicht mehr aus einem festen Schema bestimmen kann, sondern daß für jede Aktion eine neue Funktion erzeugt wird, die die URLs dafür erzeugt ( z. B. edit_item_path() um ein Objekt vom Typ item zu editieren). Man braucht dazu diese Funktion, außerdem ist kollidiert das Schema mit dem alten Schema. Ich sehe bisher keinerlei Vorteil in dem neuen Schema, es stiftet nur Verwirrung, wie die diversen Fragen und Rückfragen und die Notwendigkeit zu weiteren Erläuterungen belegen (siehe z. B. hier).

Nun könnte man sagen, daß man das einfach ignoriert und mit dem alten Schema weiterprogrammiert, was im Prinzip ja geht. Dummerweise erzeugen die neuen Scaffolding-Funktionen neuen Code der dann inkompatibel mit dem alten Schema ist. Bisher habe ich nicht nachvollzogen, was die sich dabei gedacht haben. Ich sehe aber wieder einmal die Tendenz, irgendetwas einzuführen, weil es irgendeinen Acronym-Namen hat.

2 Kommentare (RSS-Feed)

TomK32
27.5.2008 22:52
Kommentarlink

Glaub mir, es hat seine Vorteile. Zum einen wirst du die Controller fast immer auf die sieben Methoden beschränken und zum anderen hat man etwas mehr Sicherheit (gegen XSS) weil die Methoden ja nur noch auf die entsprechende request method reagieren. Ich mag REST inzwischen sehr 🙂


Hadmut
28.5.2008 0:31
Kommentarlink

Naja, gut, ich hab jetzt ein paar Tage damit vor mich hinprogrammiert.

Es ergibt schon einen gewissen Sinn, wenn man mal die Idee dahinter verstanden hat und sich darauf einläßt, einen gewissen Vorteil sehe ich in der Verschachtelung von Controllern.

Daß die Methoden nur noch auf bestimmte requests reagieren, stimmt zwar, ist aber keine zwingende Folge von REST, das könnte man auch ohne.

Vor allem ärgert mich die mangelhafte Dokumentation. Man kann seinen Rails-Kram nicht so weiterbetreiben, wie bisher, wie man ihn ändern muß, ist aber auch nicht gleich klar, weil das nicht alles so ganz durchsichtig ist.

Und die Situation “lassen wie es ist” geht nicht und “auf das neue API bringen” geht auch nicht so wirklich gut, find ich nicht so prickelnd.

Nicht jede Komplexitätssteigerung ist eine Verbesserung.