IOException.de

HTTP ist vermutlich das erfolgreichste Anwendungsprotokoll überhaupt. Ohne HTTP wäre das WWW nicht denkbar, und ein wesentlicher Teil des gesamten Internet-Traffics ist auf HTTP zurückzuführen. HTTP ist ein zustandsloses, Request-Response basiertes Protokoll, das heißt es gibt ein (einziges) Muster, über das die beteiligten Kommunikationspartner Daten austauschen: Clients initieren immer die Kommunikation, fordern eine Resource per Request an, und Server antworten wiederum per Response. Je nach Art der Anfrage, können sowohl Request als auch Response Nutzdaten, sogenannte Entities enthalten. Im überwiegenden Fall sind das HTML-Dokumente oder Mediendateien, die bei der Response übermittelt werden.

Die eigentliche Semantik des Aufrufs im Sinne von HTTP bestimmt die verwendete Methode, die Bestandteil des Requests ist. Das absolute Arbeitstier des Webs ist GET, allerdings existieren noch weitere Methoden: POST, HEAD, PUT, DELETE und OPTIONS. Deren Bedeutung und korrekte Verwendung ist allgemein jedoch weniger bekannt. Deswegen möchte ich diese Methoden kurz vorstellen und ihre Funktionen erklären. Dafür gehe ich nun zunächst auf die verschiedenen Merkmale ein, die Methoden besitzen nach RFC 2616 können.

Eine Methode gilt als sicher, wenn sie keine Seiteneffekte erzeugt. Mögliche Seiteneffekte wären zum Beispiel das Ändnern einer Resource oder das Durchführen eines Logouts. Zu einem gewissen Grad sind auch Seiteneffekte bei sicheren Methoden erlaubt. Allerdings nur dann, wenn sie nicht explizit vom Benutzer intendiert sind. Darunter fallen zum Beispiel Logfiles, die Zugriffe aufzeichnen oder Zähler, die Zugriffe aufsummieren.

Als idempotent bezeichnet man eine HTTP Methode dann, wenn die mehrfache Ausführung eines Requests die gleichen Seiteneffekte besitzt wie ein einmaliges Ausführen. Ob ein Request für das Löschen einer Resource einfach oder mehrfach ausgeführt wird, das Resultat bleibt ist identisch, die Resource wurde gelöscht. Idempotenz ist für verteilten Systemten eine interessante Aufrufsemantik, da sie es im Fehlerfall ermöglicht, einen Request zu wiederholen (At-least-once). Bei nicht idempotenten Methoden ist dies nicht möglich. Ein Beispiel hierfür wäre eine Onlinebanking-Sitzung, die zur Übermittlung einer Überweisung eine nicht-idempotente Methode verwendet. Bricht nun während des Requests die Verbindung ab, so ist unklar, ob eine erneute Ausführung zu mehrfachen Überweisungen führt oder nicht (in der Praxis wird dies z.B. durch Tokens auf Anwendungsebene verhindert).

Eine dritte Eigenschaft einer Methode ist Möglichkeit, ob bei ihrer Verwendung Responses gecachet werden können. Es ist offensichtlich, dass dies nur für Methoden ohne Seiteneffekte funktioneren kann. Ebenfalls ist Caching nur dann sinnvoll und erlaubt, wenn die Responses entsprechende Caching-Informationen bereitstellen. Dies ist unter anderem möglich durch die Angabe von Expire-Zeiten, Datum der letzten Änderungen oder Entity-Tag-Angaben. Sie beschreiben, wie lange das Resultat einer Response weiterverwendet werden kann, ohne einen erneuten Request zu versenden. Beziehungsweise geben sie an, wie bei einem konditionellen Request übermittelt werden kann, was die bekannte Version des Entities ist. Sofern sich die Resource nicht verändert hat, muss sie somit nicht erneut übertragen werden.

GET
GET ist die meistverwendete Methode und dient zur Abfrage einer Resource. Sie ist sowohl sicher als auch idempotent, und erlaubt Caching. Erweiterte Funktionen von GET erlauben konditionale Abfragen, sowie partielle Abfragen. Ersteres erlaubt eine effiziente Benutzung von Caching, um nur dann eine Resource erneut zu laden, wenn sie sich auch wirklich verändert hat oder aktualisiert wurde. Letzteres dient dazu, nur Teile einer Resource abzurufen. Das kann zum Beispiel bei einer Resource, die eine Videodatei darstellt, hilfreich sein und erlaubt das Springen im Bytestream des Videos.

HEAD
HEAD besitzt prinzipiell die gleiche Semantik wie GET, allerdings wird keine Repräsentation der Resource mitgesendet, das heißt die Response enthält kein Entity. Somit ist HEAD nützlich, um Metadaten über die Resource abzufragen, oder überhaupt des Existenz zu überprüfen.

PUT
Mit PUT kann eine Resource erstellt oder ersetzt werden. Hierfür ist im Request ein Entity enthalten, dass eine neue Repräsentation der Resource enthält. Die zu erstellende/ändernde Resource wird durch die URI eindeutig beschrieben.

DELETE
DELETE entfernt die durch die URI identifizierte Resource.

POST
Als letzte Methode wird POST für alle weiteren Aufrufe verwendet, insbesondere wenn keinerlei Zugeständnisse bezüglich der Semantiken gemacht werden (können), insbesondere Idempotenz. In der Praxis dient POST ebenfalls zum Erzeugen und Ändern von Resourcen, aber auch für viele weitere Aktionen, die via POST quasi ‘getunnelt’ werden.

Für weitere Informationen empfiehlt es sich, RFC 2616 zu lesen.