Idempotenz: Regeln und Begrifflichkeit
Dieser Beitrag ist eine Begriffserklärung zu Idempotenz in HTTP/REST – inklusive Prüfungsfragen, Praxisbeispiel und Tags.
In a Nutshell
Idempotenz bedeutet, dass eine identische Operation beliebig oft mit demselben Ergebnis ausgeführt werden kann (formal: f(f(x)) = f(x)). In HTTP/REST ist das zentral für sichere Retries, Fehlertoleranz und Nebenwirkungskontrolle.
Kompakte Fachbeschreibung
Idempotenz ist eine Eigenschaft einer Operation, nicht „nur“ eines Endpunkts. In HTTP gelten GET/HEAD/PUT/DELETE als idempotent (GET/HEAD zusätzlich „safe“). POST ist nicht idempotent, kann aber über Muster wie Idempotency Key idempotent gestaltet werden.
Wichtig ist die Abgrenzung:
- Safe: keine serverseitige Zustandsänderung (z.B. GET)
- Idempotent: Wiederholung erzeugt keine zusätzlichen Nebenwirkungen (z.B. PUT)
Für konkurrierende Updates helfen ETag + If-Match (sonst z.B. 412 Precondition Failed). In verteilten Systemen mit Retries ist Idempotenz ein Muss.
Prüfungsrelevante Stichpunkte
- Definition
f(f(x)) = f(x); Eigenschaft der Operation - HTTP: GET/HEAD safe+idempotent; PUT/DELETE idempotent; POST nicht idempotent
- POST idempotent machen: Idempotency Key + Dedupe-Store + deterministische Antworten
- Statuscodes: 200/201/204, 409 Conflict, 412 Precondition Failed, 429 Too Many Requests
- IHK: Nebenwirkungen nachvollziehbar, Korrelation-IDs, Retry-Regeln dokumentieren
- Security: Schutz vor Replay (zeitlich begrenzte Keys, Signaturen)
- Wirtschaftlichkeit: weniger Doppelbuchungen/Support
- Doku: OpenAPI beschreibt Idempotenz/Keys/TTL/Fehlerkatalog
Kernkomponenten
- Safe vs idempotent
- Methodensemantik (GET/PUT/PATCH/DELETE/POST)
- ETag + If-Match
- Dedupe-Store (Key → Response) mit TTL
- Konflikte/Fehlercodes (409/412)
- Idempotency Key pro Geschäftsvorfall
- Outbox/Inbox-Pattern
- Retry-Strategie (Backoff, 429/Retry-After)
- Observability (Correlation IDs)
- Tests (Wiederholungs-/Parallelitätstests)
Praxisbeispiel (idempotentes POST)
POST /payments
Headers: Content-Type: application/json
Idempotency-Key: pay-123-abc
Body: { "orderId": 42, "amount": 59.98, "method": "card" }
Server:
- wenn Key bereits vorhanden → gespeicherte Antwort zurückgeben
- sonst Payment erstellen, Antwort speichern (TTL z.B. 24h)
Vorteile und Nachteile
Vorteile
- Sichere Retries
- Schutz vor Doppelbuchungen
- Robustere Integrationen
Nachteile
- Dedupe-Store + Logik/Komplexität
- Semantik/TTL muss klar definiert sein
Typische Prüfungsfragen (mit Kurzantwort)
- Safe vs idempotent? Safe = keine Zustandsänderung; idempotent = wiederholbar ohne Zusatzwirkung.
- Wie machst du POST idempotent? Idempotency Key + Dedupe-Store + deterministische Antworten.
- Rolle von ETag/If-Match? Schutz vor verlorenen Updates; bei Konflikt 412.
- Welche Risiken ohne Idempotenz? Doppelte Nebenwirkungen (Zahlungen), Inkonsistenzen, hohe Supportkosten.
Freie Antwort
Idempotenz ist Basis für robuste Systeme mit Retries/Timeouts. Dokumentiere die Semantik pro Operation, inklusive erlaubter Statuscodes bei Wiederholung und TTL der Keys. In Messaging-Systemen müssen Konsumenten idempotent sein (Inbox/Outbox).
Lernstrategie
- Öffentliche Payment-API analysieren (Idempotency Keys).
- Zustandsdiagramme für PUT/DELETE/POST erstellen.
- Statuscodes/Headers zu Szenarien zuordnen.
- Deterministische Antworten sicherstellen.
Themenanalyse
- Kern: Methodensemantik, Deduplizierung
- Herausforderungen: Nebenwirkungen, Race Conditions
- Sicherheit: Replay-Schutz
- Doku: OpenAPI + Fehlerkatalog
- Wirtschaftlichkeit: weniger Incidents