Një API porosish mund të pranojë header-in Idempotency-Key dhe sërish të krijojë dy porosi për të njëjtën blerje. Nëse pas skadimit të afatit të përgjigjes klienti gjeneron një çelës të ri, serveri që shmang dublimet sipas çelësit nuk mund ta lidhë riprovimin me kërkesën fillestare.
Rreziku ekziston edhe në server: nëse kontrolli i çelësit dhe regjistrimi kryhen veçmas, dy kërkesa konkurruese mund të konstatojnë se çelësi mungon. Për ta shmangur këtë, çelësi dhe porosia duhet të ruhen në mënyrë atomike, brenda së njëjtës transaksion.
Një laborator me Python dhe SQLite e demonstron problemin duke ruajtur porosinë dhe duke ndërprerë qëllimisht përgjigjen. Përdoruesi mund ta riprovojë kërkesën dhe të kontrollojë databazën. Krijohen vetëm regjistrime lokale, pa debituar portofol. Kërkohen Python 3.10 ose më i ri, sqlite3 dhe curl, pa varësi të palëve të treta; shtatë testet kaluan me Python 3.13.3 në macOS.
Në API-në demonstruese, kërkesa e parë kthen statusin 201; përsëritja me të njëjtin çelës kthen 200 dhe të njëjtin ID porosie. Këto rregulla ndryshojnë mes API-ve, ndaj duhet ndjekur kontrata e shërbimit të integruar. Serveri është vetëm për mësim lokal: nuk ka autentikim klientësh apo izolim tregtarësh, ndërsa http.server nuk rekomandohet për prodhim.
Burimi: DEV Community (Web Dev Feed) — lexoni artikullin e plotë në anglisht.
