Ü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:
Wie Sie sicher feststellen konnten, ist nicht viel passiert, das Überschreiben des BODY erfolgte nur temporär im lokalen Browser, wenn auch Ihre Eingabe in das Textfeld per AJAX zum Server geschickt wurde. Ergo verändern auch diese Requestmethoden die serverseitigen Ressourcen nicht. Es sei denn, dafür wurde serverseitig gesorgt, aber dazu später.
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. 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.
Jede per HTTP übertragene Datei hat sowohl im Request als auch in der Response untenstehenden Aufbau:
| Header: Value |
|---|
| Header: Value |
| Header: Value |
| Message-Body |
Beliebig vielen Header-Zeilen folgt also stets eine Leerzeile und dann ggf. ein Message-Body. Sofern es Letzteren gibt, ist im Header Content-Length dessen Länge in Bytes angegeben.
Bei einem POST oder PUT können 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. Weitere Content-Types in Sachen strukturierte Daten sind application/json und application/xml und selbstverständlich sind die Möglichkeiten, Daten zu serielisieren praktisch unbegrenzt.
Merke: Der gesendete Content-Type gibt an, wie der Message-Body zu verarbeiten ist.
Eine Solche vermittelt zwischen Client und Server welche Zustände und welche Zustandsübergänge es in einer Anwendung gibt. Schlüsselparameter sind von der Länge her unbedeutend und lassen sich an jeden URL anhängen oder als Custom-Request-Header senden. Serverseitig entscheidet eine Kontrollstruktur darüber wie mit dem Request zu verfahren ist, welchen Inhalt die Response hat und mit welchem Content-Type sie ausgeliefert wird. Unabhängig von der Requestmethode können im Messagebody beliebige Nutzdaten gesendet werden. Zustände einer Anwendung, Zustandsübergänge sowie die ganze Geschäftslogik werden auf Schlüsselparametern abgebildet.
Das Common-Gateway-Interface dient dazu, sämtliche Parameter eines HTTP-Requests nachgelagerten Prozessen (Perl, PHP, C, usw.) zur Verfügung zu stellen. In C liefert z.B. getenv("CONTENT_TYPE") den Wert zu dem entsprechenden Requestheader, in Perl sind sämtliche Parameter im Hash %ENV zu finden und PHP-Programmierer bedienen sich des Array $_SERVER. Ein im Request gesendeter Message-Body wartet bytegenau in STDIN darauf gelesen zu werden und der Webserver bekommt seine Daten ebenfalls aus STDIN, also das was PHP, C oder Perl nach STDOUT geliefert hat. Der ganze Sinn und Zweck des CGI/1.1.-Standards besteht darin, die Bestandteile des HTTP-Protokolls wie z.B. die Requestmethode aus der Anwendung rauszuhalten, das Protokoll HTTP also für Client-Server-Anwendungen transparent zu machen.
Die CGI-Schnittstelle wurde mit dem Ziel entwickelt, das HTT-Protokoll für Client-Server-Anwendungen transparent zu machen. Das heißt, daß z.B. die Request-Methode in der Anwendung selbst gar keine Rolle mehr spielt und das gilt auch für alle weiteren einen HTTP-Request-Responsezyklus begleitenden Parameter. So beschreibt eine REST-Schnittstelle auch nur eine proprietäre Art und Weise wie HTTP-Requests verarbeitet werden.
Jede Anwendung, egal ob Desktopanwendungen oder Webanwendungen, lassen sich durch Zustände beschreiben. Fassen Wir diesen Artikel als Teil einer Webanwendung auf, so beschreibt allein der URL /rest.html den Zustand des Darstellen bestimmter Inhalte. Man könnte nun einen Zustandsübergang herbeiführen indem man via POST oder PUT einen HTTP-Message-Body an ebendiesen URL sendet. Und je nachdem, wie die serverseitige Verarbeitung programmiert ist, wird die Antwort auf einen solchen Request ausfallen. Sofern ein bestimmter Request dazu führt, daß serverseitig eine neue Ressource entsteht, könnte man auf diese Ressource umleiten und so eine bestimmte Sicht auf diese erzeugen. Man könnmte sich aber auch darauf beschränken, dem client einfach nur mitzuteilen, daß seine Aktion, die mit einer bestimmten Requestmethode oder anderen Parametern ausgeführt wurde, erolgreich war oder nicht.
... beschreibt den Inhalt der im Message-Body gesendeten Datei, so sieht es die HTTP-Spezifikation vor. Tatsächlich gibt es eine Unzahl an klassifizierten Content-Types, siehe Apache mime.types file. Im Sinne von Webservices ist diese Datei jedoch überflüssig wenn nicht sogar unsinnig. Denn bei einem Webservice der über Schlüsselparameter gesteuert wird, entscheiden ebendiese darüber was das Programm serverseitig machen soll und nicht der mitgegebene Content-Type.
Datenschutzerklärung: Diese Seite dient rein privaten Zwecken. Auf den für diese Domäne installierten Seiten werden grundsätzlich keine personenbezogenen Daten erhoben. Das Loggen der Zugriffe mit Ihrer Remote Adresse erfolgt beim Provider soweit das technisch erforderlich ist. sos@rolfrost.de.