Articles

Vad är en Idempotent Operation ?

introduktion

i den här artikeln ser vi vad en idempotent operation är, varför idempotency är användbar, och vi tittar på idempotency i vila.

Vad är Idempotens?

enkelt uttryckt kan vi utföra en idempotent operation flera gånger utan att ändra resultatet.

dessutom får operationen inte orsaka några biverkningar efter det första framgångsrika utförandet.

låt oss titta på två enkla exempel.

2.1. Absolutvärde

en funktion som Returnerar absolutvärdet är idempotent; oavsett hur ofta vi tillämpar det på samma nummer returnerar det alltid samma resultat.

låt oss överväga funktionen:

då är följande sant:

exempel:

däremot är en funktion som vänder tecknet på ett tal inte idempotent:

sedan:

exempel:

2.2. Uppdatera adress

ett annat praktiskt exempel på en idempotent operation skulle vara att uppdatera kontaktinformationen för en användare i systemet. Låt oss säga att vi bara uppdaterar telefonnumret. Biverkningen av denna uppdatering är att vi skickar ett textmeddelande med en verifieringskod till det nya numret. Vi har tre möjliga scenarier:

  • det första uppdateringsmeddelandet behandlades framgångsrikt, numret uppdaterades i systemet och textmeddelandet skickades. När uppdateringsmeddelandet skickas igen kommer ingenting att hända. Dessutom skickas inte textmeddelandet för andra gången.
  • den första uppdateringen misslyckas. Systemet uppdateras inte och inget textmeddelande skickas. Om den andra uppdateringen lyckas uppdateras systemet och textmeddelandet skickas.
  • den första uppdateringen misslyckas. Innan en annan uppdatering skickas inaktiveras användaren i systemet. Eftersom systemtillståndet har ändrats påverkar inte en andra uppdatering av telefonnumret.

varför Idempotens?

Idempotence säkerställer att samma begäran leder till samma systemtillstånd, och ingen åtgärd utförs oavsiktligt mer än en gång.

som ett exempel, låt oss titta på en begäran från sender S att skicka pengar via en betalningstjänst PS till mottagaren R.

3.1. Icke-Idempotent exempel

här är den icke-idempotenta versionen av begäran:

i det första försöket skickar S en begäran om att skicka $10 till R. PS tar emot meddelandena; den faktiska överföringen misslyckas dock. PS sends returnerar ett felmeddelande till S som inte får det meddelandet på grund av ett nätverksfel.

S vet inte om överföringen lyckades, så han försöker igen. Den här gången är överföringen till R framgångsrik och PS skickar ett bekräftelsemeddelande till S. återigen misslyckas bekräftelsen och S vet inte om överföringen lyckades eller inte.

därför försöker han för tredje gången. PS tar emot meddelandet, ser det som en ny begäran, skickar pengarna till R, och returnerar en bekräftelse till S.

detta är inte en idempotent begäran eftersom vi avsåg att försöka igen samma betalning och inte skicka den två gånger.

3.2. Idempotence Key

betalningar är ett bra exempel för att illustrera varför idempotence är användbart. I det föregående exemplet har vi sett att betalningen till R utförs flera gånger eftersom S går i pension utan att veta att överföringen redan hade lyckats.

Om operationen var idempotent skulle det inte ha varit fallet. Men hur vet PS att S bara har försökt samma betalning igen och vill inte skicka en andra betalning på $10 till s?

För att uppnå detta inkluderar S en idempotensnyckel i sin begäran till PS. Denna nyckel kan till exempel vara en UUID. Om PS får en begäran med samma idempotence-nyckel vet den att det är ett försök igen. Om den inte har sett nyckeln tidigare vet den att det är en ny begäran.

låt oss titta på idempotent-versionen av föregående exempel:

här är första försöket och första försöket samma som i den icke-idempotenta versionen, förutom att begäran innehåller idempotence-tangenten (65TH68M5 i vårt exempel).

den viktiga skillnaden är den andra försök igen: PS tar emot meddelandet, upptäcker att ett meddelande med samma idempotence-nyckel redan har behandlats framgångsrikt och returnerar en bekräftelse till S utan att skicka pengarna till R igen.

här är fördelen med idempotency att S kan försöka igen så många gånger han vill utan att behöva oroa sig för en dubbelbetalning. PS behöver inte oroa sig för att S får bekräftelsen, eftersom han vet att S kan försöka igen om han inte har fått meddelandet.

nackdelen med detta tillvägagångssätt är att PS måste lagra alla mottagna nycklar. Det kan vara bra om det inte finns många förfrågningar; men om förfrågningsfrekvensen är mycket hög kan det vara problematiskt. En lösning kan vara att utgå idempotence-nyckeln efter en tid.

Idempotens och vila

4.1. Översikt

Låt oss ta en kort titt på hur idempotency gäller HTTP-verb, som är viktiga att förstå när vi vill bygga ett REST API. En mycket detaljerad referens av alla HTTP-verb finns i RFC 7231.

Följande tabell visar vilka verb som är (eller borde vara) idempotenta.

4.2. Idempotent Operations

GET, HEAD och OPTION är tydligt idempotent eftersom de bara läser data, men skapar inte, uppdaterar eller tar bort några resurser.

PUT är idempotent eftersom det uppdaterar en resurs eller skapar en ny om den inte finns. Om vi skickade samma uppdatering flera gånger bör resursen inte ändras.

4, 3. Icke-Idempotent Operations

POST behöver inte vara idempotent eftersom det skapar en ny resurs och, om den kallas igen, skapar vanligtvis en annan resurs. Det kan dock implementeras som en idempotent operation också.

PATCHOPERATIONEN uppdaterar en resurs delvis och behöver inte nödvändigtvis vara idempotent. Låt oss titta på ett exempel för att förstå skillnaden mellan PUT och PATCH bättre:

låt oss säga att vi vill lägga till ett objekt i en kundvagn i en onlinebutik. Om vi använder PUT måste vi skicka hela kundvagnsdata, inklusive alla artiklar som redan finns i kundvagnen. Med PATCH kan vi bara skicka objektet som ska läggas till, och det kommer att bifogas listan över artiklar som redan finns i kundvagnen.

om vi skickar PATCHFÖRFRÅGAN igen kommer samma objekt att läggas till igen. Naturligtvis, som För POST, kan vi implementera en idempotent PATCH också.

4, 4. HTTP-svar

det är viktigt att notera att flera samtal till en idempotent-operation inte nödvändigtvis resulterar i samma HTTP-svar.

PUT returnerar till exempel 201 (Skapad) om en resurs skapas, eller 200 (OK) eller 203 (Inget innehåll) om en resurs uppdaterades.

en radering kan till exempel returnera 200 (OK) eller 204 (Inget innehåll) när en faktisk radering sker. Eventuella efterföljande samtal kommer att returnera 404 (Hittades inte).

slutsats

i den här artikeln såg vi vad idempotens betyder, vad är fördelarna med idempotens och hur det relaterar till vila.

Även om den allmänna betydelsen av idempotence är lätt att förstå, kan det vara ganska knepigt att överväga alla finesser som biverkningar och HTTP-svar under utformningen av ett API.