Dieser Artikel war eigentlich in ähnlicher Form für Dev-Comm gedacht, aber da die Seite momentan von kaum jemandem gelesen wird, gibts erstmal nen Post hier im Forum, den ich dann später umarbeite.
Bei der Arbeit an der Würfelorgie Seite, die ich mit Ruby on Rails schreibe, bin ich über RESTful Rails gestolpert, worauf scheinbar die Mehrheit aller Rails-Coder total abfährt. RESTful Rails ist, wie der Name schon vermuten lässt, eine Implementierung von REST für Rails. Ich hab mir einige Gedanken gemacht, ob ich es einsetzen soll oder nicht und die Argumente dafür und dagegen möchte ich euch nicht vorenthalten.
REST - Representational State Transfer
REST ist ein Webstandard oder viel mehr eine Richtlinie, die vorsieht, dass jede Ressource über eine eigene URI* addressiert werden kann. Das geschieht beispielsweise im Format http://host/typ/id, etwa http://www.youtube.com/user/DFYX oder auch http://de.wikipedia.org/wiki/REST, wobei sowohl die Wikipedia als auch Youtube das Konzept nur sehr inkonsequent anwenden. Nämlich da, wo REST sich von anderen Vorgehensweisen drastisch unterscheidet. Aktionen wie "anzeigen", "erstellen", "löschen" und "bearbeiten" stehen nicht in der URI, sondern werden über die HTTP Zugriffsmethode (oder vergleichbares, wenn ein anderes Protokoll zum Einsatz kommt) beim Aufruf übergeben. Aus GET http://www.multimediaxis.de/newthrea...stthread&f=115 (so habe ich diese Seite grade aufgerufen) würde dann vielleicht POST http://www.multimediaxis.de/forums/115/threads, POST http://www.multimediaxis.de/forums/w...cklung/threads oder irgendwas in der Art werden.
Die Vorteile
Diese standardisierte Form der URIs macht es natürlich sehr einfach, Programme zu schreiben, die auf die Ressourcen zugreifen und sie verändern können, besonders, wenn die Website zusätzlich zu HTML-Seiten auch XML-Dokumente, die nur die jeweilige Ressource beinhalten, anbietet. Man könnte also beispielsweise ein Verwaltungstool schreiben oder Webanwendungen miteinander kommunizieren lassen. Mehr als cURL und ein XML-Parser sind nicht nötig, um die Kommunikation zustande zu bekommen.
Die Nachteile
Das große Problem bei REST ist die Sache mit den HTTP Methoden. Die meisten User werden sich die Seite als (X)HTML anzeigen lassen und das sieht leider vor, dass alle Links mit GET aufgerufen werden. Das method-Attribut gibt es nur für <form> und nicht für <a>. Damit bleibt nur eine Lösung mit JavaScript, was nicht wirklich elegant ist und noch dazu alle User ohne JavaScript aussperrt. Und das bei einem Standard, der einen einfachen und einheitlichen Zugriff auf Websites ermöglichen soll. Doch selbst, wenn es irgendwann eine Möglichkeit geben sollte, diese Hürde zu überwinden (oder ich sie bis jetzt einfach übersehen habe), dann bleibt noch das Problem, dass man zu eher uneleganten Mitteln greifen muss, wenn man mal mehr Aktionen braucht, als nur GET, PUT, POST und DELETE.
Fazit
Ich finde die Idee wirklich toll, sie sorgt für saubere und leicht verständliche URIs und die Implementierung ist besonders mit einem Ressourcenorientierten Framework wie Rails (aber mit etwas Arbeit auch mit PHP) einfach, aber an der technischen Umsetzung in Bezug auf andere Standards haperts. Deshalb werde ich wohl vorerst die Finger davon lassen. Wer aber eine Website baut, die ohnehin nicht ohne JavaScript auskommt, der sollte unbedingt mal einen Blick drauf werfen.
* was ist eigentlich korrekt: der URI oder die URI? Logischer wäre der, aber umgangssprachlich üblicher ist eigentlich die. Selbst im Wikipediaartikel über REST wird beides kreuz und quer verwendet.
Zitieren
