Der letzte Rest: GET, PUT, POST, DELETE ...

Über die glückliche Verwendung von HTTP-Methoden in Verbindung mit der auszuführenden Aktion

Na, dann wollen wir mal, GET haben Sie bestimmt schon kennengelernt, wenn nicht, klicken Sie einfach mal hier, das macht ein GET. Und, haben Sie dabei was feststellen können?

Richtig! GET fordert eine HTTP-Ressource an, aber hier ist, weil es hier um REST geht, GET was ganz Besonderes, denn es fordert genau diese Seite an, die Sie hier gerade lesen. Dabei können Sie so oft klicken wie Sie wollen, Sie werden immer wieder ganz genau dieselbe Seite zu Gesicht bekommen. Im Sinne von REST (Representational State Transfer) ist damit schonmal eine wichtige Bedingung erfüllt: GET verändert die Ressource nicht.

Kommen wir nun zum PUT. Damit Sie was put'n können, habe ich für Sie ein Formular vorbereitet, siehe untenstehend. Selbstverständlich dürfen Sie auch was post'n oder delete'n probieren Sie es einfach aus, Sie werden ja sehen, was dann passiert:

Ihr neuer Inhalt für den BODY:
Aktionen zum Testen:

Wie Sie sicher feststellen konnten, ist nicht viel passiert, das Überschreiben des BODY erfolgte nur temporär, wenn auch Ihre Eingabe in das Textfeld per AJAX zum Server geschickt wurde.

Wozu das Alles?

Das erklärte Ziel von REST besteht darin, das was gemacht werden soll, auf HTTP-Request-Methoden abzubilden, also die Aktion selbst sozusagen. Das Ziel der Aktion hingegen, wird auf einen URI umgelegt. Die Idee ist gar nicht mal so schlecht, denn abstrakt gesehen, lassen sich infolge eines an einen URL angehängten QUERY_STRING praktisch beliebig viele unterschiedliche Ressourcen erzeugen. Weitere Informationen können in den Request-Headern untergebracht werden, wie zum Beispiel der Content-Type.

Auf diese Art und Weise wird das Schema CRUD (Create, Read, Update, Delete) auf HTTP-Request-Methoden umgelegt und dazugehörige Services sind recht einfach zu beschreiben.

Strukturierte Daten

Freilich nun, sind die Möglichkeiten einer solchen Datenübertragung beschränkt. Außerdem dürfte es sehr umständlich sein, das Ziel jeder Aktion auf einen URI umzulegen bzw. abzubilden. Ziele sind ja nicht nur Webressourcen, sondern beispielsweise auch Artikel für einen Onlineshop. Hier wäre für jedes einzelne Attribut eines Artikels ein URI zu definieren, Preis, Lagerbestand usw. Das bedeutet aber auch, dass jedes Update, Create oder Delete eines eigenen Request bedarf, wenn die Daten des Message-Body nicht weiter strukturiert sind. Letzterer enthält beispielsweise entweder den Preis oder den Warenbestand, nicht jedoch beides gleichzeitig.

Ansonsten können bei einem POST oder PUT im Message-Body beliebige Daten, sprich Bytesequenzen übertragen werden, also auch Imges, Video, Grafik usw. Und das heißt wiederum, dass eine Strukturierung der Daten natürlich auch im Message-Body eines HTTP-Request erfolgen kann. Bekanntlich erlauben Content-Type: application/x-www-form-urlencoded und Content-Type: multipart/form-data eine Strukturierung der zu übertragenden Daten. Des Weiteren application/json und application/xml.

Und selbstverständlich dürfen sich Programmierer auch eigene Algorithmen ausdenken zum Serialisieren von Daten. Gerade wenn es um größere Datenmengen geht, ist XML ziemlich umständlich. JSON ist da schon etwas schlanker, letztendlich jedoch müssen die Sequenzen nicht für einen Menschen sondern maschinenlesbar sein.

Aktion von Request Methode unabhängig

Content-Type: application/octet-stream wäre menschenlesbar und eine solche im Message-Body gesendete Sequenz kann sämtliche Anweisungen beinhalten, die serverseitig ausgeführt werden sollen. In Fakt kann per Sequenz ein DELETE angewiesen sein aber die Request-Methode ist gar nicht DELETE sondern PUT. Und das Ziel der Aktion ist auch nicht im URI abgebildet sondern auch das ist Inhalt der mit PUT gesendeten Sequenz.

Ungezählte andere Verfahren sind zweckmäßiger und effizienter als REST. Es kommt nur darauf an, die Daten im Message Body entsprechend zu verpacken und zweckmäßig heißt, dass die Verpackung definitiv nicht XML oder JSON ist.


Anbieter: nmq​rstx-18­@yahoo.de, die Seite verwendet funktionsbedingt einen Session-Cookie und ist Bestandteil meines nach modernen Aspekten in Perl entwickelten Frameworks.