Bevezetés

ebben a cikkben megnézzük, mi az idempotent művelet, miért hasznos az idempotency, és megnézzük az IDEMPOTENCY nyugalomban.

mi az Idempotence?

egyszerűen fogalmazva, egy idempotent műveletet többször is végrehajthatunk az eredmény megváltoztatása nélkül.

továbbá a művelet nem okozhat mellékhatásokat az első sikeres végrehajtás után.

nézzünk két egyszerű példát.

2.1. Abszolút érték

az abszolút értéket visszaadó függvény idempotent; függetlenül attól, hogy milyen gyakran alkalmazzuk ugyanarra a számra, mindig ugyanazt az eredményt adja vissza.

tekintsük a függvényt:

akkor a következő igaz:

példa:

ezzel szemben egy olyan függvény, amely egy szám jelét megdönti, nem idempotent:

ezután:

példa:

2.2. Frissítési cím

az idempotent művelet másik gyakorlati példája a felhasználó elérhetőségeinek frissítése a rendszerben. Tegyük fel, hogy csak a telefonszámot frissítjük. A frissítés mellékhatása az, hogy szöveges üzenetet küldünk egy ellenőrző kóddal az új számra. Három lehetséges forgatókönyvünk van:

• az első frissítési üzenet sikeresen feldolgozásra került, a számot frissítették a rendszerben, a szöveges üzenetet pedig elküldték. Amikor a frissítési üzenet újra elküldésre kerül, semmi sem fog történni. Továbbá, a szöveges üzenet nem küldött másodszor.
• az első frissítés sikertelen. A rendszer nem frissül, és nem küld SMS-t. Ha a második frissítés sikeres, a rendszer frissül, a szöveges üzenet pedig elküldésre kerül.
• az első frissítés sikertelen. Egy másik frissítés elküldése előtt a felhasználó deaktiválódik a rendszerben. Mivel a rendszer állapota megváltozott, a telefonszám második frissítése nem befolyásolja.

miért Idempotence?

az Idempotence biztosítja, hogy ugyanaz a kérés ugyanahhoz a rendszerállapothoz vezessen, és egyetlen művelet sem hajtható végre véletlenül többször.

példaként nézzük meg a feladó s kérését, hogy pénzt küldjön PS fizetési szolgáltatáson keresztül a Vevőnek R.

3.1. Nem Idempotent Példa

Itt a nem-idempotent változata a kérés:

az első próbálkozás, S küld egy kérést küld $10-R. PS megkapja az üzeneteket; azonban a tényleges átadása meghiúsul. A PS hibaüzenetet küld azoknak, akik hálózati hiba miatt nem kapják meg ezt az üzenetet.

S nem tudja, hogy az átadás sikeres volt-e, ezért újra megpróbálja. Ezúttal az R-re történő átutalás sikeres, a PS pedig ismét visszaigazoló üzenetet küld az S-nek, a visszaigazolás sikertelen, S nem tudja, hogy az átutalás sikeres volt-e vagy sem.

ezért harmadik alkalommal próbálkozik. A PS megkapja az üzenetet, új kérésnek tekinti, elküldi a pénzt R-nek, majd visszaigazolást küld az S-nek.

Ez nem egy idempotent kérés, mert ugyanazt a fizetést kívántuk újra kipróbálni, nem pedig kétszer elküldeni.

3.2. Idempotence Key

a kifizetések jó példa annak illusztrálására, hogy miért hasznos az idempotence. Az előző példában láttuk, hogy az R-nek történő fizetés többször is végrehajtásra kerül, mert s visszavonul anélkül, hogy tudná, hogy az átutalás már sikeres volt.

Ha a művelet idempotent volt, akkor ez nem így lett volna. De honnan tudja a PS, hogy s csak megismételte ugyanazt a kifizetést, és nem akarja, hogy küldjön egy második kifizetés $10 S?

ennek eléréséhez s idempotence kulcsot tartalmaz a PS-hez intézett kérésében. Ez a kulcs lehet például egy UUID. Ha a PS kérést kap ugyanazzal az idempotence kulccsal, akkor tudja, hogy újra próbálkozik. Ha még nem látta a kulcsot, akkor tudja, hogy ez egy új kérés.

nézzük meg az előző példa idempotens verzióját:

itt az első próbálkozás és az első próbálkozás megegyezik a nem idempotens verzióval, kivéve, hogy a kérés tartalmazza az idempotence kulcsot (példánkban 65th68m5).

a fontos különbség a második próbálkozás: A PS megkapja az üzenetet, megállapítja, hogy egy azonos idempotence kulccsal rendelkező üzenet már sikeresen feldolgozásra került, majd visszaigazolást ad vissza az S-nek anélkül, hogy a pénzt újra elküldené R-nek.

itt az idempotency előnye, hogy S annyiszor próbálkozhat újra, amennyit csak akar, anélkül, hogy aggódnia kellene a kettős fizetés miatt. A PS-nek nem kell aggódnia, hogy s megkapja a megerősítést, mivel tudja, hogy s újra próbálkozhat abban az esetben, ha nem kapta meg az üzenetet.

ennek a megközelítésnek az a hátránya, hogy a PS-nek minden fogadott kulcsot tárolnia kell. Ez rendben lehet, ha nincs sok kérés; ha azonban a kérés gyakorisága nagyon magas, akkor problémás lehet. Megoldás lehet az idempotence kulcs lejárata egy idő után.

Idempotence and REST

4.1. Áttekintés

vessünk egy rövid pillantást arra, hogy az idempotency hogyan vonatkozik a HTTP igékre, amelyek fontosak ahhoz, hogy megértsük, amikor REST API-t akarunk építeni. Az összes HTTP ige nagyon részletes hivatkozása megtalálható az RFC 7231-ben.

következtetés

ebben a cikkben láttuk, mit jelent az idempotence, milyen előnyökkel jár az idempotence, és hogyan kapcsolódik a pihenéshez.

annak ellenére, hogy az idempotence általános jelentése könnyen érthető, meglehetősen bonyolult lehet minden olyan finomságot figyelembe venni, mint a mellékhatások és a HTTP válaszok az API tervezése során.