Wie bilden HTTP-Methoden auf CRUD ab, und was bedeuten safe und idempotent?

Beispiele

PUT /users/42 sendet die gesamte Repräsentation und ersetzt sie; PATCH /users/42 sendet nur die zu ändernden Felder (z. B. { "email": "[email protected]" }).

Safe vs. idempotent

Das sind zwei verschiedene Eigenschaften:

• Safe — die Methode verändert den Server-State nicht (read-only). GET, HEAD, OPTIONS sind safe.
• Idempotent — denselben Request N-mal zu senden hat denselben Effekt wie einmal. GET, PUT, DELETE, HEAD sind idempotent.

Warum es wichtig ist

Interviewer fragen das, um zu sehen, ob du die HTTP-Semantik gut genug verstehst, um zuverlässige APIs zu bauen. Die Safe-/Idempotent-Unterscheidung ist nicht akademisch: sie bestimmt direkt, was Clients, Proxies und CDNs tun dürfen. Safe-Methoden können frei gecacht und vorabgeholt (prefetched) werden; idempotente Methoden können nach einem Netzwerk-Timeout automatisch erneut versucht werden, ohne das Risiko doppelter Seiteneffekte — weshalb ein Client ein PUT oder DELETE gefahrlos wiederholen kann, aber bei einem POST vorsichtig sein muss (es könnte zwei Orders anlegen). Der klassische Fehler ist, GET zum Auslösen von Seiteneffekten zu verwenden (z. B. GET /users/42/delete), was Caching bricht und Crawler versehentlich Daten mutieren lässt. Die richtige Methode zu wählen — und ihren Safe-/Idempotenz-Vertrag zu respektieren — ist das, was eine API vorhersehbar und sicher macht, um Tooling darum herum zu bauen.