Articles

Wat is een Idempotente operatie?

Inleiding

In dit artikel zullen we zien wat een idempotente operatie is, waarom idempotentie nuttig is, en we zullen kijken naar idempotentie in rust.

Wat Is Idempotentie?

simpel gezegd kunnen we een idempotente operatie meerdere keren uitvoeren zonder het resultaat te veranderen.

bovendien mag de operatie geen bijwerkingen veroorzaken na de eerste succesvolle uitvoering.

laten we eens kijken naar twee eenvoudige voorbeelden.

2.1. Absolute waarde

een functie die de absolute waarde retourneert is idempotent; het maakt niet uit hoe vaak we het toepassen op hetzelfde getal, het retourneert altijd hetzelfde resultaat.

Laten we eens kijken naar de functie:

Dan is het volgende waar is:

Voorbeeld:

In tegenstelling, een functie die klapt het teken van een getal is niet idempotent:

Hierna:

Voorbeeld:

2.2. Update Address

een ander praktisch voorbeeld van een idempotente operatie zou zijn om de contactgegevens van een gebruiker in het systeem bij te werken. Laten we zeggen dat we alleen het telefoonnummer bijwerken. Het neveneffect van deze update is dat we een sms met een verificatiecode naar het nieuwe nummer sturen. We hebben drie mogelijke scenario ‘ s:

  • het eerste updatebericht is succesvol verwerkt, het nummer is in het systeem bijgewerkt en het sms-bericht is verzonden. Wanneer het updatebericht opnieuw wordt verzonden, zal er niets gebeuren. Ook wordt het sms-bericht niet voor een tweede keer verzonden.
  • de eerste update mislukt. Het systeem wordt niet bijgewerkt en er wordt geen sms-bericht verzonden. Als de tweede update succesvol is, wordt het systeem bijgewerkt en wordt het sms-bericht verzonden.
  • de eerste update mislukt. Voordat een nieuwe update wordt verzonden, wordt de gebruiker in het systeem gedeactiveerd. Omdat de systeemstatus is veranderd, heeft een tweede update van het telefoonnummer geen invloed.

waarom Idempotentie?

Idempotence zorgt ervoor dat dezelfde aanvraag tot dezelfde systeemstatus leidt en dat geen enkele actie meer dan één keer per ongeluk wordt uitgevoerd.

als voorbeeld, laten we eens kijken naar een verzoek van afzender s om geld te sturen via een betaaldienst PS naar de ontvanger R.

3.1. Niet-Idempotent voorbeeld

Hier is de niet-idempotente versie van het verzoek:

bij de eerste poging stuurt S een verzoek om $10 naar R. PS ontvangt de berichten; de daadwerkelijke overdracht mislukt echter. PS stuurt een foutmelding naar S die dat bericht niet ontvangt vanwege een netwerkfout.

S weet niet of de overdracht succesvol was, dus probeert hij het opnieuw. Deze keer is de overdracht naar R succesvol, en PS stuurt een bevestigingsbericht naar S. nogmaals, de bevestiging mislukt, en S weet niet of de overdracht succesvol was of niet.

daarom probeert hij het voor de derde keer. PS ontvangt het bericht, beschouwt het als een nieuw verzoek, stuurt het geld naar R en stuurt een bevestiging terug naar S.

Dit is geen idempotent verzoek omdat we van plan waren om dezelfde betaling opnieuw te proberen en niet twee keer te verzenden.

3.2. Idempotence Key

betalingen zijn een goed voorbeeld om te illustreren waarom idempotence nuttig is. In het vorige voorbeeld hebben we gezien dat de betaling aan R meerdere keren wordt uitgevoerd omdat S met pensioen gaat zonder te weten dat de overdracht al succesvol was geweest.

als de operatie idempotent was, zou dit niet het geval zijn geweest. Maar hoe weet PS dat S net dezelfde betaling opnieuw heeft geprobeerd en wil geen tweede betaling van $10 naar S sturen?

om dit te bereiken, bevat S een idempotentiesleutel in zijn verzoek aan PS. Deze sleutel kan bijvoorbeeld een UUID zijn. Als PS een verzoek ontvangt met dezelfde idempotence sleutel, weet het dat het een retry is. Als het de sleutel nog niet eerder heeft gezien, weet het dat het een nieuw verzoek is.

laten we eens kijken naar de idempotente versie van het vorige voorbeeld:

Hier zijn de eerste poging en de eerste poging hetzelfde als in de niet-idempotente versie, behalve dat het verzoek de idempotentie sleutel bevat (65TH68M5 in ons voorbeeld).

het belangrijke verschil is de tweede poging: PS ontvangt het bericht, vindt dat een bericht met dezelfde idempotence sleutel al met succes is verwerkt, en retourneert een bevestiging naar S zonder het geld opnieuw naar R te sturen.

Hier is het voordeel van idempotency dat S het zo vaak kan proberen als hij wil zonder zich zorgen te maken over een dubbele betaling. PS hoeft zich geen zorgen te maken dat S de bevestiging ontvangt, omdat hij weet dat S het opnieuw kan proberen als hij het bericht niet heeft ontvangen.

het nadeel van deze aanpak is dat PS alle ontvangen sleutels moet opslaan. Dit kan prima zijn als er niet veel verzoeken zijn; als de aanvraagfrequentie echter erg hoog is, kan dit problematisch zijn. Een oplossing kan zijn om de idempotence sleutel na enige tijd te laten verlopen.

Idempotentie en rust

4.1. Overzicht

laten we een korte blik werpen op hoe idempotentie van toepassing is op HTTP-werkwoorden, die belangrijk zijn om te begrijpen wanneer we een REST API willen bouwen. Een zeer gedetailleerde referentie van alle HTTP-werkwoorden is te vinden in RFC 7231.

de volgende tabel toont welke werkwoorden idempotent zijn (of zouden moeten zijn).

4.2. Idempotente operaties

GET, HEAD en OPTION zijn duidelijk idempotent omdat ze alleen gegevens lezen, maar geen bronnen aanmaken, bijwerken of verwijderen.

PUT is idempotent als het een bron bijwerkt of een nieuwe maakt als het niet bestaat. Als we dezelfde update meerdere keren hebben verzonden, moet de bron niet veranderen.

4.3. Niet-Idempotente bewerkingen

POST hoeft niet idempotent te zijn omdat het een nieuwe bron aanmaakt en, indien opnieuw aangeroepen, gewoonlijk een andere bron aanmaakt. Echter, het kan worden geà mplementeerd als een idempotente operatie ook.

De PATCHOPERATIE werkt een bron gedeeltelijk bij en hoeft niet per se idempotent te zijn. Laten we eens kijken naar een voorbeeld om het verschil tussen PUT en PATCH beter te begrijpen:

stel dat we een item willen toevoegen aan een winkelwagentje in een online winkel. Als we PUT gebruiken, moeten we de volledige winkelwagengegevens verzenden, inclusief alle items die al in de winkelwagen zitten. Met PATCH kunnen we alleen het item verzenden dat moet worden toegevoegd en het wordt toegevoegd aan de lijst met items die al in de winkelwagen staan.

als we het PATCHVERZOEK opnieuw verzenden, wordt hetzelfde item opnieuw toegevoegd. Natuurlijk, wat POST betreft, kunnen we ook een idempotent PATCH implementeren.

4.4. HTTP Response

Het is belangrijk op te merken dat meerdere aanroepen naar een idempotente operatie niet noodzakelijk resulteren in hetzelfde HTTP-antwoord.

PUT zal bijvoorbeeld 201 (aangemaakt) retourneren als een bron is aangemaakt, of 200 (OK) of 203 (geen inhoud) als een bron is bijgewerkt.

een DELETE, bijvoorbeeld, kan 200 (OK) of 204 (geen inhoud) retourneren wanneer een werkelijke delete plaatsvindt. Alle volgende oproepen zullen 404 (niet gevonden) retourneren.

conclusie

In dit artikel zagen we wat idempotentie betekent, wat de voordelen zijn van idempotentie en hoe het zich verhoudt tot rust.

hoewel de algemene betekenis van idempotentie gemakkelijk te begrijpen is, kan het heel lastig zijn om alle subtiliteiten zoals bijwerkingen en HTTP-reacties te overwegen tijdens het ontwerp van een API.