Frage zu REST und HTTP

[alexander_ro]

Hallo Debianfreunde,

nachdem Gott und/oder die Welt überall nur noch Restfull sehen (möchten) habe ich mir das auch mal angeschaut. Und folgendes Buch (REST und HTTP Stefan Tilkov aus dem dpunkt.verlag) zu Thema gelesen. Die Worte las ich wohl aber allein der Glaube fehlt mir.

Wenn ich den Autor richtig verstehe geht es doch dabei in der Haupsache darum auch die anderen HTTP-Methoden zu benutzen. Also nicht nur GET und POST sondern auch die Stiefkinder des Protokolls PUT und DELETE. Sicher wenn es das Protokoll anbietet warum nicht nutzen. Den großen Nutzen sehe ich indies aber nicht dabei.

Eine URI: www.xyz.de/Programm?Kunde=0815 ist meiner Meinung nach genauso eine Resource wie www.xyz.de/Kunde/0815. Nur muß man die letztere per mod_rewrite oder ähnlichem in etwas umschreiben das dann tatsächlich auch ausgeführt werden kann. Auch in der verständlichkeit und lesbarkeit sehe ich keinen Unterschied.

Wenn man die Werte aus dem Query-String gegen eine lange Liste von rewrites tauscht ist das das typische Teufel/Belzebub Problem?

Was mich auch stört ist der Umstand das man für weitere Funktionen wie Scrollbare Listen dann doch wieder Parameter per Query-String übergeben muß. Also warum dann nicht gleich eine konsitente einheitliche Lösung machen und alle Steuerinformationen und Nutzdaten per POST senden. Ich sehe eigentlich in der einheitlichkeit das einfache und nicht in dem Durcheinander das in dem Buch beschrieben wird. Da selbst der Autor zu gibt das man sich in manchen Situationen nur mit Krücken helfen kann. Wie gesagt ähm geschrieben macht mich REST nicht restlos glücklich.

Wie ist denn eure Meinung zu REST?
und evtl. auch Beispiele wie Ihr URIs aufbaut und die übergabe von Steuer- und Nutzdaten gelöst habt.

Grüße
Alexander

[novalix]

Hi,
das spannende an REST ist halt, dass man mit den standardisierten Hausmitteln des Web Programmlogik abbilden kann, zu der man ansonsten nur über die jeweilige Implementierung mit $Programmiersprache anschliessen kann.
Zweitere sind, auch wenn das API offen spezifiziert ist, notwendig proprietär, da es nun mal keine Standardisierung dafür gibt (geben kann), wie eine bestimmte Funktionalität noch dazu in unterschiedlichen Programmiersprachen zu implementieren wäre.
Natürlich ist auch ein Restful API nicht immer gleich und im Detail tückenreich. Man kann aber davon ausgehen, dass in zehn vielleicht auch in zwanzig Jahren die Anschlussfähigkeit immer noch gegeben ist.

Jetzt muss ich aber auch noch gestehen, dass ich selber noch keine weitreichenden Erfahrungen mit REST gemacht habe. Ein Webprojekt, in dessen Zentrum eine Client Library für eine solche API steckt, ist auf meiner TODO-Liste mit "Someday" getaggt.
Das Projekt steht also. Jetzt müssen nur noch die fiesen kleinen Details wie Programmierung der Library, Erstellung der Datenlogik inklusive Persitenzstruktur und die Implementierung des Webfrontends realisiert werden, oh my. Ne Brigade Heinzelmännchen wäre nicht schlecht.

Letztlich erscheint mir REST weniger als der grosse technologische Wurf, als eine Möglichkeit einigermaßen übersichtlich an Programmlogik anzuschliessen bzw. diese bereit zu stellen.

Groetjes, niels

[alexander_ro]

Hi,

danke für Deine Antwort. Aaaabbber ...

das spannende an REST ist halt, dass man mit den standardisierten Hausmitteln des Web Programmlogik abbilden kann, zu der man ansonsten nur über die jeweilige Implementierung mit $Programmiersprache anschliessen kann.

Stimmt schon gilt aber auch nur für Funktionen die sich mit GET, PUT, POST und DELETE darstellen lassen (Klassische Datenbankanwendungen). Was meiner Meinung nach bei weitem nicht immer möglich ist. Ich gebe gerne zu das der Autor das anders als ich sieht.

Zweitere sind, auch wenn das API offen spezifiziert ist, notwendig proprietär, da es nun mal keine Standardisierung dafür gibt (geben kann), wie eine bestimmte Funktionalität noch dazu in unterschiedlichen Programmiersprachen zu implementieren wäre.

REST beschreibt doch nur die Schnittstelle aber nicht die Implementierung der Anwendung. In meinem Fall sind es C++ Programme. Man möge mir den Frevel das ich nicht PHP oder Java benutze verzeihen.

Man kann aber davon ausgehen, dass in zehn vielleicht auch in zwanzig Jahren die Anschlussfähigkeit immer noch gegeben ist.

Also wenn keiner in 10 oder 20 Jahren http(s) und die Methoden GET und POST abschaft kann man alles andere auch noch anbinden. Schaft jemand http(s) oder GET und POST ab wirds für REST auch eng.

Ne Brigade Heinzelmännchen wäre nicht schlecht.

Stimmt. Die haben sich angekündigt lassen aber noch auf sich warten. Derweilen bleibt mir auch nix anderes übrig als alles selber zu machen. Ich muß und werde vermutlich REST auch nicht verwendenden war nur mal so eine Technologiestudie. Ich modernisiere gerade die Programme für meinen Online-Shop also Klassen die ich noch selbst gemacht habe aber in der zwischenzeit Boost besseren Ersatz anbietet austauschen und Design schwächen die sich über die Jahre gezeigt haben ausbauen. Auserdem hatte ich vor das dann als OpenSource auch anderen zur Verfügung zu stellen wird aber vermutlich so keiner benutzen wollen. Wer mag schon Webanwendungen die in C++ Programmiert sind. Ich benutze auch viel OpenSource also sollen andere wenn Sie wollen meine Entwicklung dann auch benutzen können.

Letztlich erscheint mir REST weniger als der grosse technologische Wurf, als eine Möglichkeit einigermaßen übersichtlich an Programmlogik anzuschliessen bzw. diese bereit zu stellen.

Hm ... stimmt und stimmt mich nachdenklich, ich habe nicht die Programmlogik sondern die Prozesslogik. Also den Ablauf der Geschäftsprozesse in der Datenbank (LDAP) das finde ich übersichtlicher und man kann mit diversen Tools sich hübsche Grafiken machen die immer UptoDate sind weil ja aus der Produktiven Datenbank erzeugbar. Mir ist unklar wie man die Endlosen URI-Listen bei einer halbwegs komplexen Anwendung verwalten soll.

Das Programm liest nur aus der Datenbank was zu tun ist und führt dann die dazu nötigen Module aus. Die Daten des Produktkatalogs liefert dann eine PostgreSql Datenbank noch dazu. Dann wird alles ein wenig gerührt (nicht geschüttelt) und mit CSS, JavaScript und HTML angereichert und zum Client geschickt. Je nach User und Berechtigung für Front- und Backoffice verschieden.

Grüße
Alexander