HTTP-Methoden

HTTP-Methoden im Überblick: GET, HEAD, POST, PUT, PATCH, DELETE, OPTIONS, CONNECT, TRACE und WebDAV, mit sicher, idempotent und cachebar nach RFC 9110, Beispielen und CORS-Preflight-Prüfung.

Methode	Sicher	Idempotent	Cachebar	Body in der Anfrage	Standard
`GET`	Ja	Ja	Ja	ohne definierte Bedeutung	RFC 9110
`HEAD`	Ja	Ja	Ja	ohne definierte Bedeutung	RFC 9110
`POST`	Nein	Nein	nur mit Frische-Angabe und Content-Location	Ja	RFC 9110
`PUT`	Nein	Ja	Nein	Ja	RFC 9110
`DELETE`	Nein	Ja	Nein	ohne definierte Bedeutung	RFC 9110
`CONNECT`	Nein	Nein	Nein	ohne definierte Bedeutung	RFC 9110
`OPTIONS`	Ja	Ja	Nein	möglich, ohne definierte Bedeutung	RFC 9110
`TRACE`	Ja	Ja	Nein	Nein (verboten)	RFC 9110
`PATCH`	Nein	Nein	nur mit Frische-Angabe und Content-Location	Ja	RFC 5789

CORS: Wird ein OPTIONS-Preflight gesendet?

Methode

Content-Type der Anfrage

Eigene Header (kommagetrennt)

Suchen

Gruppe

Methoden aus RFC 9110

GET

Ruft eine Darstellung der Ressource ab. Sicher und idempotent, Antworten sind standardmäßig cachebar. Parameter stehen in der URL (Query-String); ein Body hat keine definierte Bedeutung und wird von vielen Servern abgelehnt.

GET /api/kunden/42 HTTP/1.1
Host: example.com
Accept: application/json

HEAD

Wie GET, aber der Server sendet nur Statuszeile und Header, keinen Inhalt. Nützlich, um Größe (Content-Length), Typ oder Änderungsdatum zu prüfen, ohne die Datei zu laden.

HEAD /download/handbuch.pdf HTTP/1.1
Host: example.com

POST

Übergibt Daten zur Verarbeitung durch die Ressource: Formular absenden, Eintrag anlegen, Aktion auslösen. Weder sicher noch idempotent; ein doppelter Aufruf kann doppelte Bestellungen erzeugen. Neu angelegte Ressourcen meldet der Server meist mit 201 Created und Location.

POST /api/kunden HTTP/1.1
Host: example.com
Content-Type: application/json

{"name": "Erika Mustermann"}

PUT

Ersetzt die Ressource unter der angegebenen URL vollständig durch den gesendeten Inhalt oder legt sie dort an. Idempotent: mehrfaches Senden derselben Anfrage ergibt denselben Zustand. Antwort 200, 204 oder bei Neuanlage 201.

PUT /api/kunden/42 HTTP/1.1
Host: example.com
Content-Type: application/json

{"name": "Erika Mustermann", "ort": "Köln"}

DELETE

Löscht die Zuordnung der Ressource zur URL. Idempotent: ein zweites DELETE ändert nichts mehr, auch wenn es 404 liefert. Antwort meist 204 No Content oder 200.

DELETE /api/kunden/42 HTTP/1.1
Host: example.com

OPTIONS

Fragt ab, welche Methoden und Optionen eine Ressource unterstützt (Antwort-Header Allow). Browser senden OPTIONS als CORS-Preflight, bevor sie eine nicht einfache Cross-Origin-Anfrage stellen.

OPTIONS /api/kunden/42 HTTP/1.1
Host: api.example.com
Origin: https://www.example.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: content-type

CONNECT

Baut über einen Proxy einen Tunnel zum Zielserver auf, typischerweise für HTTPS. Die Anfrage-URL ist nur Host und Port (authority-form).

CONNECT www.example.com:443 HTTP/1.1
Host: www.example.com:443

TRACE

Lässt den Server die empfangene Anfrage zurückspiegeln (Antwort mit Content-Type message/http), zur Fehlersuche entlang einer Proxy-Kette. Auf öffentlichen Servern meist deaktiviert, weil es Header mit Zugangsdaten offenlegen kann.

TRACE / HTTP/1.1
Host: example.com
Max-Forwards: 2

PATCH

PATCH

Ändert eine Ressource teilweise anhand einer Änderungsbeschreibung, zum Beispiel JSON Merge Patch (RFC 7396) oder JSON Patch (RFC 6902). Nicht automatisch idempotent; mit If-Match und ETag lassen sich Konflikte vermeiden.

PATCH /api/kunden/42 HTTP/1.1
Host: example.com
Content-Type: application/merge-patch+json
If-Match: "a1b2c3"

{"ort": "Bonn"}

WebDAV (RFC 4918)

PROPFIND

Liest Eigenschaften (Metadaten) einer Ressource oder eines Verzeichnisses; Tiefe über den Header Depth. Sicher und idempotent.

PROPFIND /dateien/ HTTP/1.1
Host: dav.example.com
Depth: 1

PROPPATCH

Setzt oder entfernt Eigenschaften einer Ressource. Idempotent, nicht sicher.

PROPPATCH /dateien/bericht.odt HTTP/1.1
Host: dav.example.com
Content-Type: application/xml

MKCOL

Legt eine Sammlung (Verzeichnis) an. Idempotent, nicht sicher.

MKCOL /dateien/neu/ HTTP/1.1
Host: dav.example.com

COPY

Kopiert eine Ressource an das Ziel im Header Destination. Idempotent, nicht sicher.

COPY /dateien/a.txt HTTP/1.1
Host: dav.example.com
Destination: https://dav.example.com/dateien/b.txt

MOVE

Verschiebt oder benennt eine Ressource um (Header Destination). Idempotent, nicht sicher.

MOVE /dateien/a.txt HTTP/1.1
Host: dav.example.com
Destination: https://dav.example.com/archiv/a.txt

LOCK

Sperrt eine Ressource gegen gleichzeitige Änderungen. Weder sicher noch idempotent.

LOCK /dateien/bericht.odt HTTP/1.1
Host: dav.example.com
Timeout: Second-3600

UNLOCK

Hebt eine Sperre auf (Header Lock-Token). Idempotent, nicht sicher.

UNLOCK /dateien/bericht.odt HTTP/1.1
Host: dav.example.com
Lock-Token: <urn:uuid:…>

Alles läuft in Ihrem Browser. Eingaben verlassen Ihr Gerät nicht.

GET und POST, PUT vs PATCH: die Unterschiede

HTTP-Methoden (auch HTTP Request Methoden oder Verben) sagen dem Server, was mit einer Ressource geschehen soll. Die Tabelle fasst die Eigenschaften nach RFC 9110 zusammen: Sicher heißt, die Methode ist nur lesend gedacht. Idempotent heißt, mehrfaches Senden derselben Anfrage hat dieselbe Wirkung wie einmaliges, deshalb dürfen Clients und Proxys sie nach einem Verbindungsabbruch wiederholen. Cachebar heißt, Antworten dürfen zwischengespeichert werden. Jede Methode steht unten mit einer Beispielanfrage zum Kopieren.

Der Klassiker GET und POST: GET liest Daten und überträgt Parameter in der URL, POST schickt Daten im Body zur Verarbeitung. GET-Anfragen tauchen in Logs, Verläufen und Lesezeichen auf, für Passwörter oder personenbezogene Daten ist POST daher die richtige Wahl. Bei PUT vs PATCH geht es um vollständiges oder teilweises Ändern: PUT ersetzt die ganze Ressource und ist idempotent, PATCH ändert nur die übermittelten Felder und ist es nicht zwingend.

Der Rechner für den OPTIONS Preflight zeigt, ob ein Browser vor einer Cross-Origin-Anfrage erst per OPTIONS um Erlaubnis fragt. Das passiert bei allen Methoden außer GET, HEAD und POST, bei Content-Types wie application/json und bei eigenen Headern wie Authorization. Die Statuscodes der Antworten finden Sie in den HTTP-Statuscodes, die Header in der HTTP-Header-Referenz. Grenzen: Ob ein Server sich an die Semantik hält, ist seine Sache; die Tabelle beschreibt den Standard.

Anleitung: HTTP-Methoden in 4 Schritten

In der Tabelle oben ablesen, welche Methode sicher, idempotent und cachebar ist und ob sie einen Body in der Anfrage hat.
Im CORS-Bereich Methode, Content-Type und eigene Header wählen, um zu sehen, ob der Browser einen OPTIONS-Preflight sendet.
Im Feld „Suchen“ oder über „Gruppe“ eine Methode aus RFC 9110, PATCH oder WebDAV aufrufen.
Die Beispielanfrage mit „Kopieren“ übernehmen und für eigene Tests anpassen.

Typische Anwendungsfälle

REST-API entwerfen: Für jede Aktion die passende Methode wählen, etwa PUT zum Ersetzen und PATCH für Teiländerungen.
CORS-Fehler verstehen: Prüfen, warum eine Anfrage mit application/json einen Preflight auslöst und welche Header der Server erlauben muss.
Wiederholungen absichern: Klären, welche Anfragen ein Client nach einem Timeout gefahrlos erneut senden darf.
WebDAV-Zugriff: Methoden wie PROPFIND für Dateiserver nachschlagen.

Fragen

Häufige Fragen

Was bedeutet idempotent bei HTTP?

Eine Methode ist idempotent, wenn mehrere identische Anfragen dieselbe Wirkung auf dem Server haben wie eine einzige. Das gilt für GET, HEAD, PUT, DELETE, OPTIONS und TRACE, nicht für POST und PATCH. Idempotente Anfragen dürfen nach einem Verbindungsfehler automatisch wiederholt werden.

Was ist der Unterschied zwischen PUT und PATCH?

PUT ersetzt die Ressource vollständig durch den gesendeten Inhalt; fehlende Felder gehen verloren. PATCH sendet nur eine Änderungsbeschreibung, etwa die geänderten Felder als JSON Merge Patch. PUT ist idempotent, PATCH nicht zwingend.

Darf eine GET-Anfrage einen Body haben?

RFC 9110 verbietet ihn nicht, gibt ihm aber keine Bedeutung. Viele Server, Proxys und Bibliotheken ignorieren oder verwerfen ihn. Für Suchanfragen mit vielen Parametern nutzt man daher Query-Parameter oder POST.

Wann sendet der Browser einen OPTIONS Preflight?

Bei Cross-Origin-Anfragen per fetch oder XMLHttpRequest, die keine einfachen Anfragen sind: andere Methoden als GET, HEAD und POST, andere Content-Types als application/x-www-form-urlencoded, multipart/form-data und text/plain oder eigene Header wie Authorization. Der Server muss mit passenden Access-Control-Allow-Headern antworten.

Welche HTTP-Methoden sind sicher?

GET, HEAD, OPTIONS und TRACE gelten nach RFC 9110 als sicher, weil sie nur lesen sollen. Sicher heißt nicht ungefährlich: Ein Server kann auch bei GET Daten ändern, verstößt dann aber gegen die vorgesehene Bedeutung.

Wann verwende ich POST und wann PUT?

POST, wenn der Server die neue Ressource anlegt und ihre URL bestimmt, etwa POST /api/kunden. PUT, wenn der Client die URL kennt und die Ressource dort vollständig ersetzt oder anlegt; PUT ist idempotent, POST nicht.

Welcher Statuscode passt zu einer erfolgreichen DELETE-Anfrage?

Meist 204 No Content, wenn keine Antwort folgt, oder 200 mit einer Statusmeldung. 202 Accepted bedeutet, dass das Löschen angenommen, aber noch nicht ausgeführt wurde.

Weitere Werkzeuge

Das könnte auch helfen

Alle 358 Werkzeuge

HTTP-Methoden

CORS: Wird ein OPTIONS-Preflight gesendet?

Methoden aus RFC 9110

PATCH

WebDAV (RFC 4918)

GET und POST, PUT vs PATCH: die Unterschiede

Anleitung: HTTP-Methoden in 4 Schritten

Typische Anwendungsfälle

Häufige Fragen

Das könnte auch helfen

HTTP-Statuscodes

HTTP-Header-Referenz

MIME-Typen

Git-Befehle

Bash-Befehle

Port-Liste