VenedyHTTP-Methoden (auch HTTP-Verben genannt) signalisieren dem Server, was mit einer Ressource geschehen soll. Jede Methode hat eine eigene Bedeutung (Semantik). Die fünf wichtigsten decken die üblichen Operationen ab:
- GET (Lesen): Fordert eine Repräsentation der angegebenen Ressource an. GET sollte nur Daten abrufen und keinen Inhalt im Request-Body senden.
- POST (Anlegen/Verarbeiten): Übergibt Daten an die Ressource, damit der Server sie nach eigener Logik verarbeitet. Löst typischerweise eine Zustandsänderung oder Seiteneffekte aus, etwa das Anlegen einer neuen Ressource oder das Absenden eines Formulars.
- PUT (Ersetzen): Erzeugt die Zielressource oder ersetzt ihren kompletten Zustand durch den im Request gesendeten Inhalt. Wird derselbe Inhalt erneut gesendet, ist das Ergebnis identisch.
- PATCH (Teil-Ändern): Wendet nur teilweise Änderungen auf eine Ressource an, ohne sie vollständig zu ersetzen.
- DELETE (Löschen): Löscht die angegebene Ressource.
Zwei Konzepte helfen bei der Auswahl der richtigen Methode:
- Sicher (safe): Eine Methode gilt als sicher, wenn ihre Semantik im Kern nur lesend ist, der Client also keine Zustandsänderung auf dem Server erwartet.
GETundHEADsind sicher;POST,PUT,PATCHundDELETEsind es nicht. - Idempotent: Eine Methode ist idempotent, wenn mehrere identische Aufrufe denselben Effekt auf dem Server haben wie ein einzelner. Laut RFC 9110 sind
PUT,DELETEsowie alle sicheren Methoden (GET,HEAD) idempotent.POSTundPATCHsind nicht idempotent.
Welche Methode wofür:
- Daten abrufen, ohne etwas zu verändern: GET.
- Neue Ressource erzeugen, wenn der Server die URL/ID vergibt, oder allgemein verarbeiten: POST.
- Ressource unter bekannter URL vollständig anlegen oder ersetzen: PUT (wiederholbar ohne Zusatzeffekte).
- Nur einzelne Felder ändern: PATCH.
- Ressource entfernen: DELETE.
Praktischer Nutzen: Idempotente Methoden (GET, PUT, DELETE) darf ein Client nach einem Netzwerkfehler gefahrlos erneut senden. Bei POST kann ein wiederholtes Senden dagegen versehentlich doppelte Ressourcen anlegen, weshalb es nicht idempotent ist.
| Methode | Beispiel | Bedeutung | Sicher | Idempotent |
|---|---|---|---|---|
| GET | GET /users/42 | lesen | Ja | Ja |
| POST | POST /users | neu anlegen (Server vergibt ID) | Nein | Nein |
| PUT | PUT /users/42 | komplett ersetzen | Nein | Ja |
| PATCH | PATCH /users/42 | nur Teilfelder ändern | Nein | Nein |
| DELETE | DELETE /users/42 | löschen | Nein | Ja |
Die fünf Methoden an der Ressource /users. Sicher heißt nur lesend, idempotent heißt: mehrfach gesendet, gleiches Ergebnis.
Ein PATCH verändert nur die mitgeschickten Felder, hier ausschließlich die E-Mail:
PATCH, nur ein Feld ändern
PATCH /users/42 HTTP/1.1
Content-Type: application/json
{ "email": "neu@example.com" }
Quellen
- HTTP request methods MDN Web Docs
- RFC 9110: HTTP Semantics RFC Editor / IETF