Tényleg mentette a munkáját az az időtúllépéses beküldés?

A gomb forog, a lap hibát mutat, és a tíz perc alatt kitöltött űrlap eltűnt. Amit nem tud, az az, hogy az írás befejeződött-e, mielőtt a kapcsolat megszakadt. Ha ezt az ismeretlent kudarcként kezeli, abból lesznek a duplikált hozzászólások, a dupla rendelések és az ismétlődő támogatási jegyek.

Rögzített sorrendben állítsa helyre: tartsa meg a szöveget, keresse meg az eredményt, és csak ezután döntse el, engedélyezett-e a második beküldés.

Kezdje a szöveggel és az időbélyeggel

Másolja ki a tartalmat az oldalról, mielőtt bármi máshoz hozzányúl, beleértve minden piszkozatot, amelyet a böngésző még a mezőben tart. Jegyezze fel az időt, az oldalt, ahol volt, és a műveletet, amelyet végrehajtott, mert ez a három adat teszi lehetővé a vizsgálat többi részét. Ha a lap még nyitva van, hagyja nyitva, amíg el nem olvasta a hálózati bejegyzést. A szöveg elmentése semmibe nem kerül, elvesztése viszont az egész feladatba.

Ezután válassza szét a két hibatípust, amelyet valóban meg tud figyelni. A kérés közben megszakadt kapcsolat és a hibával válaszoló kiszolgáló másképp néz ki a hálózati panelen, és csak a második mond valamit az alkalmazás döntéséről.

Keresse az eredményt az alkalmazás saját nézetében

Töltse újra az olvasónézetet, amely megmutatná az eredményt: a hozzászólások listáját, a rendelési előzményeket, a jegysort vagy a szerkesztett rekordot. A legutóbbi bejegyzés helyett fiók, cél, idő és tartalom szerint egyeztessen, mert más is írhatott ön után. Háttérfeladatnál a meglévő hivatkozást és annak állapotát keresse, ahelyett hogy új műveletet hozna létre kapcsolattesztként.

Ha az eredmény ott van, kész van, és a hiba a válasz útjához tartozik, nem az íráshoz. Ha nincs ott, tartsa fenn annak lehetőségét, hogy az alkalmazás még nem rögzítette: egy sorban álló feladat, késleltetett olvasónézet vagy lemaradó replika egy ideig elrejtheti a sikeres írást.

Adjon neki egy meghatározott második pillantást, mielőtt következtetésre jut, és jegyezze fel mindkét ellenőrzés idejét. Két húsz másodperccel elválasztott ellenőrzés sokkal gyengébb bizonyíték, mint két tíz perccel elválasztott ellenőrzés.

Döntse el, biztonságos-e a második beküldés

A válasz a művelettől függ, nem a türelmétől. A HTTP elválasztja azokat a metódusokat, amelyek ugyanazzal a szándékolt hatással megismételhetők, azoktól, amelyek nem, és a második fajta automatikus ismétlését ellenzi, kivéve ha tudott, hogy a szemantika engedi. Hozzászólás létrehozása, rendelés leadása és fizetés küldése általában a második csoportba tartozik, ezért a második sikeresnek tűnő kattintás semmit sem mond az elsőről.

Ha ön tartja karban a klienst, használja az API által dokumentált újrapróbálkozási vagy idempotencia-mechanizmust, és ugyanahhoz a logikai művelethez kapcsolja, ahelyett hogy minden kísérlethez új kulcsot generálna. A nyomon követésre használt kérésazonosító nem duplikátumszűrő kulcs, hacsak a kiszolgáló annak nem tekinti.

curl -i -X POST https://api.example.net/v1/orders \
  -H "Idempotency-Key: 6f1c2a94-3b7e-4a10-9c22-5d0e8f7b1a63" \
  -H "Content-Type: application/json" \
  --data @order.json

A kulcs csak akkor segít, ha a szolgáltatás a művelethez tárolja, és ismétléskor az eredeti eredményt adja vissza. Tesztelje ezt a viselkedést egy előkészítő végponton, mielőtt éles környezetben támaszkodna rá.

Gyűjtsön bizonyítékot, mielőtt bármit újra megnyom

A hiba képernyőképe helyett a hálózati bejegyzést őrizze meg. A kérés metódusa, az URL, a válasz vagy az időtúllépés és a bekövetkezés ideje az, amit egy rendszergazda az alkalmazás nyilvántartásaival össze tud vetni. Csak akkor exportálja vagy másolja a bejegyzést parancsként, ha utána eltávolítja a másolatból a sütiket, az engedélyezési fejléceket és minden privát tartalmat. Tartsa érintetlenül a saját munkamenetét, és soha ne játsszon vissza elfogott, hitelesítő adatokat tartalmazó kérést rövidítésként.

Kérdezzen meg egy konkrét dolgot a szolgáltatás tulajdonosától: sikeres volt-e a művelet ezzel a tartalommal ebben az időben, és van-e rá hivatkozás? Erre a kérdésre van válasz, míg a "elromlott-e az oldal" kérdésre nincs.

A gyakorlat lényege annak megállapítása, hogy a művelet pontosan egyszer történt meg. Egy elutasítható hibaüzenet nem ugyanaz, mint egy megbízható nyilvántartás, és az utóbbira van szüksége, mielőtt bármi mást beküldene.