POST

HTTP Methode

Spezifikation von der HTTP Methode POST

Die POST-Methode fordert die Zielressource auf, die in der Anfrage enthaltene Darstellung gemäß der spezifischen Semantik der Ressource zu verarbeiten. POST wird beispielsweise (unter anderem) für die folgenden Funktionen verwendet:

  • Übermittlung eines Datenblocks, z. B. der in ein HTML-Formular eingegebenen Felder, an einen Datenverarbeitungsprozess;
  • Posting einer Nachricht an ein Schwarzes Brett, eine Newsgroup, eine Mailingliste, einen Blog oder eine ähnliche Gruppe von Artikeln;
  • Erstellung einer neuen Ressource, die vom Ursprungsserver noch identifiziert werden muss; und
  • Anfügen von Daten an die bestehende(n) Darstellung(en) einer Ressource.

Ein Ursprungsserver zeigt die Antwortsemantik an, indem er je nach dem Ergebnis der Verarbeitung der POST-Anfrage einen geeigneten Statuscode auswählt; fast alle der in dieser Spezifikation definierten Statuscodes können in einer Antwort auf POST empfangen werden (die Ausnahmen sind 206 (Partial Content), 304 (Not Modified) und 416 (Range Not Satisfiable)).

Wenn eine oder mehrere Ressourcen auf dem Ursprungsserver als Ergebnis der erfolgreichen Verarbeitung einer POST-Anfrage erstellt wurden, SOLLTE der Ursprungsserver eine 201 (Created)-Antwort senden, die ein Location-Header-Feld enthält, das eine Kennung für die erstellte primäre Ressource (Abschnitt 7.1.2) und eine Darstellung, die den Status der Anfrage beschreibt, während sie auf die neue(n) Ressource(n) verweist.

Antworten auf POST-Anfragen sind nur dann cachefähig, wenn sie explizite Aktualitätsinformationen enthalten (siehe Abschnitt 4.2.1 von [RFC7234]). Die POST-Zwischenspeicherung ist jedoch nicht weit verbreitet. In Fällen, in denen ein Herkunftsserver möchte, dass der Client das Ergebnis einer POST so zwischenspeichern kann, dass es von einem späteren GET wiederverwendet werden kann, kann der Herkunftsserver eine 200 (OK)-Antwort senden, die das Ergebnis und ein Content-Location-Header-Feld enthält, das den gleichen Wert hat wie der effektive Request-URI der POST (Abschnitt 3.1.4.2).

Wenn das Ergebnis der Verarbeitung einer POST einer Darstellung einer existierenden Ressource entspricht, kann ein Ursprungsserver den User-Agent zu dieser Ressource umleiten, indem er eine 303 (See Other) Antwort mit dem Identifikator der existierenden Ressource im Location-Feld sendet. Dies hat den Vorteil, dass dem User-Agent ein Ressourcen-Identifikator zur Verfügung gestellt wird und die Repräsentation über eine Methode übertragen wird, die besser für gemeinsames Caching geeignet ist, allerdings auf Kosten einer zusätzlichen Anfrage, wenn der User-Agent die Repräsentation nicht bereits im Cache hat.

Die HTTP-Methode POST ist in Abschnitt 4.3.3 des Dokuments RFC 7231 von der Internet Engineering Task Force (IETF) und dem World Wide Web Consortium (W3C) spezifiziert worden.

Beschreibung der Methode POST

in Arbeit befindliche Maßnahmen

Beispiel für die HTTP Methode POST

Request header:
POST /data HTTP/1.1
Host: api.example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537
Accept: application/json
Accept-Language: de-DE,de;q=0.5
Content-Type: application/json
Content-Length: 100
Connection: keep-alive
Request body:
{
  "key": "value",
  "foo": "bar"
}
Response header:
Content-Type: application/json
Date: Mon, 31 July 2023 14:58:12 GMT
Server: Apache/2.4.7 (Ubuntu)
Cache-Control: no-cache
Location: http://api.example.com/data/123
Response body:
{
  "status": "success",
  "id": 123
}