Hvad betyder Idempotens?
Idempotens er en egenskab, der gør gentagelser håndterbare. Hvis en integration modtager samme besked to gange eller gentager et kald efter et tidsudløb, skal den ikke nødvendigvis skabe to ordrer, to opgaver eller to beskeder. Systemet skal kunne genkende den samme logiske handling.
Begrebet handler om virkningen, ikke om at alle svar eller logposter er identiske. At sætte en status til en bestemt værdi kan være idempotent, mens at lægge én til en tæller normalt ikke er det uden yderligere kontrol.
Identificér handlingen før første forsøg
En idempotensnøgle kan identificere en bestemt anmodning på tværs af genforsøg. Nøglen skal genbruges, når det er samme handling, og skiftes, når brugeren faktisk ønsker en ny handling. Opret derfor nøglen før første forsøg og gem den sammen med opgaven.
Modtageren kan gemme nøgle, parametre og resultat og afvise genbrug med modstridende data. Den præcise kontrakt varierer mellem tjenester. Nogle gemmer nøgler i en begrænset periode. Integrationen må kende denne periode og må ikke antage, at en gammel nøgle beskytter mod dubletter for altid.
Kontrollér samtidige forsøg og delvise fejl
En simpel “findes posten?”-kontrol efterfulgt af oprettelse kan fejle, hvis to processer læser samtidig og begge opretter. Der kan være brug for en unik begrænsning, transaktion eller tilsvarende atomisk registrering. Ved eksterne handlinger skal systemet også håndtere, at virkningen skete, men kvitteringen forsvandt. Idempotens er derfor både et data- og et procesdesign. En ny automatisk retrymekanisme bør ikke sættes i drift, før disse tilfælde er forstået.
Et eksempel fra praksis
En formularhenvendelse skal oprette en intern CRM-sag. Integrationen bruger formularens stabile indsendelses-ID til den logiske oprettelse. Et langsomt svar får klienten til at forsøge igen med samme identifikation. Systemet returnerer den eksisterende sag i stedet for at oprette en ny. Testen sender samtidige dubletter og kontrollerer både antallet af sager og deres indhold. En ny, reel henvendelse får et nyt ID og må naturligvis oprette en ny sag.
Typiske faldgruber
- At generere en ny nøgle ved hvert genforsøg og dermed fjerne dubletbeskyttelsen.
- At genbruge samme nøgle til to forskellige brugerønsker.
- At stole på en separat læsning og oprettelse uden kontrol af samtidighed.
Det skal I afklare
- Definér hvad der udgør én logisk handling.
- Gem og genbrug nøgle og parametre ved usikre udfald.
- Test samtidige gentagelser og modstridende genbrug.
Spørgsmål og svar
Er alle API-kald idempotente?
Nej. Det afhænger af metode og endpointets kontrakt. En integration skal ikke antage, at en oprettelse er sikker at gentage, blot fordi den bruger HTTP.
Fjerner idempotens behovet for fejlhåndtering?
Nej. Den begrænser dobbeltvirkninger, men løser ikke manglende data, adgangsfejl eller utilgængelige systemer. Der skal stadig være status, genforsøgsregler og en måde at undersøge fejl på.
Kilder og videre læsning
De tekniske begreber bygger på nedenstående kilder. Eksemplerne er illustrative og viser, hvordan I kan arbejde med emnet.
- Stripe: Idempotent requests ↗Genbrug af nøgle ved gentagelse af samme logiske anmodning.
- IETF: RFC 9110 HTTP Semantics ↗HTTP-metoder, status og idempotente forespørgsler.