HTTP-Methoden erklärt: GET, POST, PUT, PATCH, DELETE und die Semantik, die wirklich zählt

Jede HTTP-Anfrage ist ein Verb plus ein Substantiv: eine Methode, angewendet auf eine Ressource. Die meisten Entwickler wissen, dass GET holt und POST absendet — und hören dort auf, genau wo der Schmerz beginnt. Eine GET-Anfrage, die etwas löscht. Eine PUT-Anfrage, die einen Datensatz halb aktualisiert. Ein wiederholtes POST, das einen Kunden doppelt belastet. Jedes davon ist ein Methoden-Semantik-Bug, und jedes ist vermeidbar, sobald man versteht, was die HTTP-Spezifikation tatsächlich verspricht. Diese Anleitung erklärt die Methoden, die drei Eigenschaften, die sie regieren, und wie sie mit Statuscodes zusammenspielen.

Was eine HTTP-Methode wirklich bedeutet

Eine Anfragezeile wie GET /users/42 HTTP/1.1 ist ein Versprechen an den Server darüber, wonach Sie fragen. Die URL benennt, welche Ressource; die Methode benennt, welche Operation Sie darauf ausgeführt haben wollen. Diese Trennung ist das ganze Design: Dieselbe URL bedeutet unter verschiedenen Methoden Verschiedenes, weshalb ein einzelner /articles/7-Endpunkt dasselbe lesen, ersetzen, patchen und löschen kann.

Drei in RFC 9110 definierte Eigenschaften regieren alles Weitere, und fast jeder Methoden-Bug führt auf ihre Verwechslung zurück:

• Sicher (safe) — die Anfrage ändert den Serverzustand nicht. Sichere Methoden können von Crawlern, Link-Vorschauen und Prefetch-Engines ohne Konsequenzen ausgeführt werden.
• Idempotent — die Anfrage N-mal zu wiederholen erzeugt denselben Serverzustand wie einmal. Idempotenz ist, was Retries sicher macht.
• Cachebar — die Antwort darf von Caches (Browser, CDN, Reverse Proxy) gespeichert und wiederverwendet werden.

Merken Sie sich, welche Methode welche Eigenschaft hat, und der Großteil des Designs fällt an seinen Platz.

Die fünf Methoden, die Sie täglich nutzen

GET — eine Ressource lesen. Sicher, idempotent, cachebar. Es sollte eine Repräsentation zurückgeben und nichts ändern. In dem Moment, in dem Sie eine Mutation hinter einen GET-Endpunkt setzen — einen ?action=delete-Query-Parameter, ein Zähler-Inkrement, einen Login, der ein Cookie setzt —, haben Sie eine Anfrage erschaffen, die jeden Cache, Prefetch und Crawler bricht, der sie berührt. Verursacht eine URL Seiteneffekte, ist es kein GET.

POST — eine Ressource erstellen oder einen Prozess auslösen. Nicht sicher, nicht idempotent und nur unter ausdrücklichen Bedingungen cachebar. POST ist die Standard-„tu etwas“-Methode: einen Datensatz anlegen, ein Formular absenden, eine Logzeile anhängen, einen Job starten. Weil der Server jedes Mal eine neue Ressource anlegen kann, erzeugen zwei identische POSTs legitim zwei Datensätze — deshalb brauchen Zahlungsformulare und Bestellbuttons Idempotenzschlüssel oder Deduplizierung obendrauf.

PUT — eine Ressource vollständig ersetzen. Idempotent. PUT /articles/7 bedeutet „mache den Zustand von /articles/7 exakt gleich diesem Body.“ Senden Sie es zweimal, ist das zweite ein No-op gegen den Zustand. Die Kehrseite: PUT ist kein Teilupdate. Setzt Ihr PUT-Handler nur die im Body vorhandenen Felder, haben Sie einen PATCH in PUTs Kleidern gebaut, und zwei Clients, die verschiedene Felder aktualisieren, überschreiben sich still gegenseitig.

PATCH — eine partielle Änderung anwenden. Weder sicher noch garantiert idempotent. Der Body beschreibt Änderungen statt des Zielzustands — {"title": "neu"} aktualisiert ein Feld. Ein Patch wie „den Aufrufzähler erhöhen“ ist echt nicht-idempotent: zweimal angewendet erhöht er zweimal. Brauchen Sie Retry-Sicherheit bei einem PATCH, nutzen Sie einen bedingten Header (If-Match mit einem ETag), damit der Server eine veraltete oder wiederholte Anfrage ablehnen kann.

DELETE — eine Ressource entfernen. Idempotent. Die bemerkenswerte Eigenheit: Ein zweites DELETE auf eine bereits verschwundene Ressource ist noch immer Erfolg. 404 Not Found geben Sie zurück, wenn die URL nie existierte; 204 No Content (oder 200) ist in Ordnung, wenn die Ressource existierte und nun weg ist. Viele naive Implementierungen geben bei jedem folgenden Delete 404 zurück, was Retry-Schleifen bricht.

Die Nebenbesetzung: HEAD, OPTIONS, CONNECT, TRACE

• HEAD — genau wie GET, aber die Antwort hat keinen Body. So prüfen Sie Existenz, Größe und Content-Type einer Ressource, ohne sie herunterzuladen. Cachebar, sicher, idempotent.
• OPTIONS — fragt den Server „was darf ich hier tun?“ Der Allow-Header der Antwort listet die erlaubten Methoden. Stark genutzt im CORS-Preflight.
• CONNECT — baut einen Tunnel auf (typischerweise TLS durch einen Proxy). Sie werden es selten direkt nutzen.
• TRACE — spiegelt die Anfrage zurück, sodass Sie sehen, was Zwischenstationen geändert haben. Auf Produktionsservern oft deaktiviert, weil es sensible Header leaken kann.

Sicher vs. idempotent vs. cachebar: Die Matrix

Methode	Sicher	Idempotent	Cachebar
GET	✅	✅	✅
HEAD	✅	✅	✅
OPTIONS	✅	✅	❌
TRACE	✅	✅	❌
PUT	❌	✅	❌
DELETE	❌	✅	❌
PATCH	❌	⚠️ (nicht garantiert)	❌
POST	❌	❌	⚠️ (nur mit expliziter Frische)

Das Muster ist es wert, verinnerlicht zu werden: Sichere Methoden sind eine Teilmenge der idempotenten plus OPTIONS/TRACE. Und cachebar folgt sicher — weil ein Cache eine Antwort nur dann sicher wiederverwenden kann, wenn ihr erneutes Abspielen keine Seiteneffekte hat. Deshalb tötet „nutze POST für alles“ still Ihre Cache-Trefferquote.

Wie Methoden mit Statuscodes zusammenspielen

Die Methode sagt dem Server, was Sie wollen; der Statuscode sagt Ihnen, was geschah. Übliche Paarungen:

• 201 Created — ein POST (oder ein PUT, das eine Ressource anlegte) war erfolgreich; der Location-Header zeigt oft auf die neue Ressource.
• 204 No Content — Erfolg mit nichts zurückzugeben (ein DELETE oder ein PUT ohne Body).
• 202 Accepted — die Anfrage wurde zur asynchronen Verarbeitung angenommen; die Ressource ist noch nicht fertig.
• 405 Method Not Allowed — die URL existiert, aber diese Methode wird darauf nicht unterstützt; der Allow-Header listet, was erlaubt ist.
• 409 Conflict — die Anfrage kollidiert mit dem aktuellen Zustand (z. B. ein PATCH im Kampf mit einer parallelen Bearbeitung, wenn If-Match scheitert).
• 501 Not Implemented — der Server unterstützt die Methode überhaupt nicht (z. B. ein Server, der CONNECT nie implementiert).

Ein schneller mentaler Test für die Paarungen: 201/204/202 sind die drei „es hat funktioniert“-Antworten, und welche Sie nutzen, kommuniziert, ob etwas Neues entstand, nichts zurückzugeben ist oder die Arbeit noch läuft. Für die vollständige Troubleshooting-Aufschlüsselung siehe die HTTP-Statuscodes-Anleitung, oder schlagen Sie jeden Code mit dem HTTP-Statusreferenz-Tool nach.

Häufige Fehler (und die Lösungen)

• GET mit Seiteneffekten. Ein GET /logout oder ein GET, das einen Zähler erhöht. Lösung: Machen Sie die Mutation zu einem POST. Prefetching, Crawler und Link-Vorschauen feuern sie sonst ungebeten ab.
• POST für jede Mutation. Es ist die einfachste Gewohnheit, verschenkt aber Idempotenz und Cachebarkeit. Lösung: Nutzen Sie PUT für vollständigen Ressourcenersatz, DELETE zum Entfernen und reservieren Sie POST für „neu erstellen“ und „Prozess ausführen“.
• PUT, das sich wie PATCH verhält. Nur geänderte Felder an einen PUT-Handler zu senden, der sie zusammenführt. Lösung: Entweder führen Sie Ganzressourcen-Semantik in PUT ein (volle Repräsentation verlangen) oder nutzen Sie PATCH für Teilupdates.
• Nicht-idempotentes DELETE. 404 für „schon gelöscht“ zurückgeben. Lösung: Behandeln Sie „weg“ als Erfolg für Retry-Sicherheit.
• POSTs ohne Dedup wiederholen. Bestellformulare, Zahlungs-Webhooks und „Create“-Aufrufe feuern bei wackeligem Netz alle doppelt. Lösung: Akzeptieren Sie einen Idempotenzschlüssel-Header und lehnen Sie Wiederholungen ab, oder machen Sie das Create selbst idempotent (z. B. ein Unique-Constraint auf eine clientseitig gelieferte ID).
• Allow ignorieren. Erhält ein Client einen 405, ist der Allow-Header des Servers der Vertrag; befolgen Sie ihn, statt den Methodennamen zu raten.

Praktische Tipps

• Testen Sie Methoden-Semantik mit einem Werkzeug, das Sie kontrollieren — curl ist der schnellste Weg, eine beliebige Methode zu senden und den exakten Statuscode und die Header zu prüfen.
• Nutzen Sie HEAD vor großen GETs, wenn Sie nur Existenz oder Größe brauchen.
• Entwerfen Sie APIs so, dass PUT und DELETE sicher wiederholbar sind, und behandeln Sie POST/PATCH als retry-unsicher, sofern Sie keinen Schutz hinzufügen.
• Denken Sie daran, dass das Browser-<form> nur GET und POST unterstützt — alles andere braucht fetch oder eine Client-Bibliothek (deshalb zwingen viele Alt-Backends alles durch POST).
• Beim Debuggen stellen Sie immer zwei Fragen: Was habe ich versprochen (Methoden-Semantik)? und Hat der Server zugestimmt (Statuscode)?

Kurzreferenz

• Anfrage = Methode + URL. GET liest, POST erstellt/verarbeitet, PUT ersetzt, PATCH aktualisiert teilweise, DELETE entfernt, HEAD prüft ohne Body, OPTIONS fragt, was erlaubt ist.
• Sicher: GET, HEAD, OPTIONS, TRACE. Idempotent: diese plus PUT und DELETE. Cachebar: GET und HEAD (standardmäßig).
• PUT = ganze Ressource ersetzen, idempotent; PATCH = Teiländerung, nicht garantiert idempotent.
• DELETE einer fehlenden Ressource ist noch immer Erfolg — kein 404 für „schon weg“.
• 201 Created / 204 No Content / 202 Accepted = die drei Geschmacksrichtungen von Erfolg; 405 + Allow = falsche Methode für diese URL.
• Wiederholen ist nur bei idempotenten Methoden sicher — deduplizieren Sie Ihre POSTs.