Ich habe gerade das Buch “RESTful PHP Webservices ” gelesen (Packt Publishing; Author: Samisa Abeysinghe).
Um es vorwegzunehmen, ich halte Webservices für etwas ganz Tolles. Kapselung des Codes, definierte Aufrufschnittstelle, Verknüpfung von heterogenen Systemen/Programmiersprachen das sind alles Pluspunkte für mich, aber nach dem Lesen des Buches erschließt sich für mich nicht, warum ich Webservices nach REST Style programmieren sollte, was mir dieser Ansatz für einen Zusatznutzen bringt.
Warum habe ich als Java Programmierer überhaupt ein PHP-Buch gelesen. Zum einen kann man nicht leugnen, dass PHP insbesondere im Bereich der Frontendprogrammierung marktrelevant ist und seit der Version PHP 5 ist die Skriptsprache stark objektorientiert. Das Buch “RESTful Java Webservices” soll erst gegen Ende des Jahres herauskommen. Kernpunkt meines Interesses war die Idee der Restprogrammierung kennenzulernen. Die Codebespiele sind in diesem Buch natürlich allesamt in PHP geschrieben, aber in welcher Programmiersprache man die grundsätzliche Idee des REST Ansatzes umsetzt (PHP oder Java) ist von zweitrangiger Bedeutung. Es ist für einen Programmierer absolut leicht den PHP-Code des Buchs zu verstehen und sich das Java Gegenstück dazu gedanklich vorzustellen.
Es wird immer wieder betont, dass REST (Representational State Transfer) keine neue Programmiersprache ist und auch kein neues Programmierframework, sondern ein Softwarearchitekturstil. Und ich glaube, dass diese Kernaussage auch den Nutzen und die Limitierung von REST beschreibt. REST wird sich nicht weiterentwicklen, weil es keine Möglichkeit zur Weiterentwicklung gibt. Stillstand ist aber in der Softwareentwicklung für jede gute Idee fatal.
In der REST Programmierung wird alles als Ressource mit eigener URI deklariert und es ist verpönt, Parameter zu übergeben.
Wenn beispielsweise der Bibliotheksbenutzer (ID=4) das Buch mit der ID= 6 ausleiht, so würde man vielleicht normalerweise
pfad/kunde.php?client=4&book=6
schreiben.
Im REST Stil mit der verpönten Parameterübergabe schreibt man dann
pfad/kunde/4/book/6
Es tut mir leid, aber ich kann dabei keinen großen Unterschied sehen. Auch wenn dies nun als Ressource (URI) geschrieben wurde, bleibt es für mich doch grundsätzlich eine Parameterübergabe.
Auch bei der REST-Schreibweise existiert physikalisch keine Datei in dem angegebenen Pfad und wir kommen zu meinem ersten Kritikpunkt an REST. Für jeden Ressourceaufruf wie pfad/kunde/4/book/6 ist ein Controller zu programmieren, der den Ressourceaufruf erst einmal wieder auseinanderbaut, um dann letztendlich die erforderlichen Verarbeitungs- bzw. Datenaufbereitungsschritte durchzuführen.
Während man bei HTTP-Aufrufen sonst nur mit GET und POST agiert, so wird von REST fast das volle Repertoire (GET, POST, PUT, DELETE) eingesetzt. Dies wird einem als großer Vorteil gegenüber einem normalen Webservice Aufruf verkauft, bei dem man den Modus explizit mitgibt. Aber ob ich nun den Modus des Webservices als Parameter übergeben bekomme oder ihn mir erst durch Betrachtung des HTTP-Befehls (GET, PUT, …) erschließen muss, bleibt sich für mich doch gleich. Der Modus muss und wird auf jeden Fall übergeben, ob auf die eine oder andere Art. Theoretisch gesehen, mag die REST Methode die sauberere Art der Modussteuerung sein, praxisbezogen würde ich sie allerdings als die schlechtere Verfahrensweise bezeichnen. Aus Sicherheitsgründen wird oft der PUT-Befehl auf Servern deaktiviert (insbesondere bei externen Serverbetreibern), so dass man mit einem Programm, welches auf der REST-Architektur basiert, ein richtiges Problem beim Deployment bekommt. Was nützt einem das beste theoretische Konzept, wenn es auf dem Produktionsserver nicht läuft!
Um die URIs aufzulösen, braucht es einen Controller, der den HTTP-Befehl auflöst, dann die Parameter (die ja keine Parameter sind) interpretiert um dann in einer Art Kaskadierung mit vielen “wenn dann” Fallbetrachtungen irgendwann einmal das zuständige Aufbereitungsprogramm/die zuständigen Aufbereitungsprogramme bestimmt zu haben.
Bei einfachen Webservices mag das ja noch angehen, wenn mit steigender Komplexität sehe ich auch eine steigende Fehlerträchtigkeit mit dieser Architektur und damit einhergehend eine Verschlechterung der Wartbarkeit der Software.
REST mag ein Softwarearchitekturstil sein, den man kennen sollte, um bei der Anwendungsarchitektur mitreden zu können, wenn jemand anfängt, mit Buzzwords (Mode-Schlagworten) wie REST zu arbeiten. Aber ich sehe darin keine, die Programmierung nachhaltig beeinflußende, richtungsweisende Neuerung.
Das Thema REST wird bald von einem anderen Strohfeuer abgelöst werden. Die durchaus vorhandenen, positiven Gedankenanstöße von REST (zustandslose Webservices, keine Notwendigkeit von Cookies) werden hoffentlich von anderen, noch kommenden Techniken aufgegriffen und weitergeführt.
REST ist und bleibt das Kapitel 5 der Dissertation von Roy Thomas Fielding aus dem Jahr 2000.
