POST
Verwendung
Eine POST-Anfrage übermittelt eine Entität an die angegebene Ressource. Der Server entscheidet anhand der eigenen Semantik der Ressource, wie die beigefügte Repräsentation zu verarbeiten ist. Anders als PUT, das auf eine bestimmte Ressourcen-URI zielt, delegiert POST die Verarbeitung an die durch die Ziel-URI identifizierte Ressource.
Der Header Content-Type gibt das Format des Anfrage-Bodys an. In HTML-Formularen und APIs sind drei Kodierungen gebräuchlich.
application/x-www-form-urlencoded
Die Standardkodierung für HTML-Formulare. Die Daten sind als Schlüssel-Wert-Paare strukturiert, die durch Kaufmanns-Und-Zeichen (&) getrennt und deren Schlüssel und Werte durch Gleichheitszeichen (=) verbunden sind. Nicht alphanumerische Zeichen verwenden Percent-Encoding.
name=Alice&role=adminmultipart/form-data
Jedes Feld belegt einen eigenen Teil, der durch eine im Content-Type-Header deklarierte Boundary-Zeichenkette abgegrenzt wird. Diese Kodierung unterstützt Binärdaten wie Datei-Uploads. Der Header Content-Disposition innerhalb jedes Teils benennt das Feld.
text/plain
Keine vorgeschriebene Struktur. Der Server verarbeitet den rohen Body gemäß seiner eigenen Logik.
Wiederholte POST-Anfragen sind nicht idempotent. Wird dasselbe Formular zweimal abgeschickt, entstehen zwei Ressourcen oder die Verarbeitung wird zweimal ausgelöst – anders als bei PUT, wo eine wiederholte Anfrage denselben Serverzustand erzeugt.
POST-Antworten sind nur dann zwischenspeicherbar, wenn die Antwort explizite Frische-Informationen und einen passenden Content-Location-Header enthält.
Formularübermittlung
Ein Client übermittelt Formulardaten im URL-kodierten Format. Der Server erstellt einen Job und antwortet mit 201 Created.
Anfrage
POST /jobs HTTP/1.1
Host: api.example.re
Content-Type: application/x-www-form-urlencoded
Content-Length: 17
name=backup&pri=2Antwort
HTTP/1.1 201 Created
Location: /jobs/47
Content-Type: application/json
Content-Length: 38
{"id":47,"name":"backup","priority":2}Multipart-Datei-Upload
Ein Client lädt eine Datei mit Multipart-Kodierung hoch. Die Boundary-Zeichenkette ----Boundary trennt die einzelnen Teile. Der Server nimmt den Upload an und gibt 202 Accepted zurück.
Anfrage
POST /uploads HTTP/1.1
Host: api.example.re
Content-Type: multipart/form-data; boundary=----Boundary
Content-Length: 196
------Boundary
Content-Disposition: form-data; name="title"
Q4 Report
------Boundary
Content-Disposition: form-data; name="file"; filename="report.pdf"
Content-Type: application/pdf
<binary data>
------Boundary--Antwort
HTTP/1.1 202 Accepted
Location: /uploads/91
Content-Length: 0JSON-API
Ein Client sendet eine JSON-Nutzlast, um einen neuen Benutzer anzulegen. Der Server gibt die erstellte Ressource mit einem id-Feld zurück.
Anfrage
POST /users HTTP/1.1
Host: api.example.re
Content-Type: application/json
Content-Length: 41
{"email":"alice@example.re","role":"ops"}Antwort
HTTP/1.1 201 Created
Content-Type: application/json
Content-Length: 50
{"id":112,"email":"alice@example.re","role":"ops"}CORS
POST ist eine CORS-safelisted Methode, allerdings nur dann, wenn der Content-Type application/x-www-form-urlencoded, multipart/form-data oder text/plain lautet. Ein POST mit application/json oder einem beliebigen anderen Inhaltstyp löst eine Preflight-OPTIONS-Anfrage aus.
POST im Vergleich zu GET
POST transportiert Daten im Anfrage-Body statt in der URL. Dadurch bleiben Parameter aus dem Browserverlauf, den Serverprotokollen und den Referer-Headern heraus, was POST besser für sensible Daten geeignet macht.
POST-Antworten werden standardmäßig nicht zwischengespeichert und lassen sich nicht als Lesezeichen speichern. POST ist weder sicher noch idempotent, weshalb wiederholte Übermittlungen doppelte Ressourcen erzeugen oder die Verarbeitung mehrfach auslösen.
POST hat praktisch keine Größenbeschränkung für den Body, während GET durch URL-Längenbeschränkungen von rund 2048 Zeichen eingeschränkt ist.
Cookies mit SameSite=Lax blockieren seitenübergreifende POST-Anfragen, erlauben seitenübergreifende GET-Anfragen jedoch. Das verleiht POST einen gewissen eingebauten CSRF-Schutz, der GET fehlt.
Sicherheit
POST-Daten erscheinen nicht in URLs, im Browserverlauf oder in Referer-Headern. Im Vergleich zu GET verringert das die Gefahr einer versehentlichen Datenpreisgabe.
Ohne geeignete Tokens ist POST weiterhin anfällig für CSRF-Angriffe. Formulare auf bösartigen Seiten senden POST-Anfragen automatisch an andere Origins. Cookies mit SameSite=Lax bieten teilweisen Schutz, indem sie die Cookie-Übertragung bei seitenübergreifenden POST-Anfragen blockieren, dedizierte CSRF-Tokens bleiben jedoch erforderlich.
POST über einfaches HTTP überträgt Daten im Klartext. HTTPS ist erforderlich, um den Anfrage-Body während der Übertragung zu schützen.
POST im Vergleich zu PATCH
POST erstellt neue Ressourcen unter vom Server gewählten URIs. PATCH verändert bestehende Ressourcen unter bekannten URIs.
POST überlässt die Verarbeitungssemantik vollständig dem Server. PATCH verfügt über definierte Patch-Formate wie JSON Patch und JSON Merge Patch, die konkrete anzuwendende Änderungen beschreiben.
Wenn ein Client bestimmte Felder einer bestehenden Ressource aktualisieren muss, ist PATCH die passende Methode. POST dient dem Erstellen neuer Ressourcen oder dem Auslösen serverseitiger Verarbeitung.