Idempotenz

Eine Operation ist idempotent, wenn ihre Wiederholung auf dem Server dieselbe Wirkung hat wie eine einmalige Ausführung. Das ist wichtig, weil Netzwerke ausfallen: Ein Client, der in einen Timeout läuft, weiß nicht, ob sein Request angekommen ist, und ein erneuter Versuch ist nur sicher, wenn der Request idempotent ist. Bei Idempotenz geht es um den Serverzustand, nicht darum, jedes Mal eine identische Response zu bekommen.

Welche HTTP-Methoden idempotent sind

Methode	Idempotent	Sicher (keine Seiteneffekte)
GET, HEAD, OPTIONS	Ja	Ja
PUT	Ja	Nein
DELETE	Ja	Nein
POST	Nein	Nein
PATCH	Nicht garantiert	Nein

Ein zweimal gesendetes DELETE /orders/42 liefert vielleicht erst 204 und dann 404. Die Responses unterscheiden sich, aber der Zustand ist derselbe: Die Bestellung ist weg. Das ist trotzdem idempotent.

PUT vs. PATCH

PUT ersetzt die gesamte Ressource durch den gesendeten Body. Wer PUT /users/7 mit {"name": "Ada", "plan": "pro"} dreimal sendet, erhält jedes Mal denselben Nutzer – also idempotent.

PATCH wendet eine Änderung an, und ob das idempotent ist, hängt von der Änderung ab. {"plan": "pro"} setzt einen Wert und ist in der Praxis idempotent. Eine Operation wie „loginCount um 1 erhöhen“ oder ein JSON-Patch-add auf ein Array liefert jedes Mal ein anderes Ergebnis, daher ist PATCH als Methode nicht garantiert idempotent.

POST sicher wiederholbar machen

Zahlungs- und Bestell-APIs akzeptieren oft einen Idempotency Key: Der Client erzeugt einen eindeutigen Wert und sendet ihn in einem Header wie Idempotency-Key. Der Server speichert das Ergebnis des ersten Requests mit diesem Key und liefert bei jeder Wiederholung dasselbe Ergebnis zurück, statt eine zweite Bestellung anzulegen.

POST /payments HTTP/1.1
Content-Type: application/json
Idempotency-Key: 6f1c2a9e-3b7d-4f0a-9c2e-1d5b8a7e4f60

{"amount": 4999, "currency": "EUR"}

So testen Sie es

• Senden Sie dasselbe PUT oder DELETE zweimal und prüfen Sie den Zustand der Ressource, nicht nur den Statuscode.
• Senden Sie dasselbe POST zweimal mit demselben Idempotency Key. Erwarten Sie eine einzige Ressource und denselben Response-Body.
• Verwenden Sie einen Key erneut mit einem anderen Body. Eine gut gestaltete API lehnt das ab, statt stillschweigend das alte Ergebnis zurückzugeben.
• Feuern Sie doppelte Requests gleichzeitig ab. Bei Race Conditions bricht die Idempotenz-Behandlung meistens.