Je ta potekla oddaja res shranila vaše delo?

Gumb se vrti, zavihek kaže napako in obrazec, ki ste ga deset minut izpolnjevali, je izginil. Česa ne veste, je to, ali je pisanje uspelo, preden je povezava umrla. Prav obravnavanje te neznanke kot neuspeha ustvarja podvojene komentarje, dvojna naročila in ponavljajoče se zahteve za podporo.

Obnovite v ustaljenem vrstnem redu: obdržite besedilo, poiščite rezultat in šele nato presodite, ali je druga oddaja dovoljena.

Začnite z besedilom in časovnim žigom

Kopirajte vsebino s strani, preden se dotaknete česar koli drugega, vključno z osnutkom, ki ga brskalnik še vedno drži v polju. Zapišite čas, stran, na kateri ste bili, in dejanje, ki ste ga izvedli, saj prav ti trije podatki omogočajo preostalo preiskavo. Če je zavihek še odprt, ga pustite odprtega, dokler ne preberete vnosa v omrežju. Shranjevanje besedila ne stane nič, izguba pa stane celotno nalogo.

Nato ločite dve vrsti okvare, ki ju res lahko opazujete. Povezava, ki je padla sredi zahteve, in strežnik, ki je odgovoril z napako, sta v omrežni plošči videti različno, in samo drugo vam pove kaj o odločitvi aplikacije.

Iščite rezultat v pogledu same aplikacije

Ponovno naložite pogled za branje, ki bi pokazal rezultat: seznam komentarjev, zgodovino naročil, čakalno vrsto zahtevkov ali zapis, ki ste ga urejali. Primerjajte po računu, cilju, času in vsebini, ne po najnovejšem vnosu, saj je kdo drug morda pisal za vami. Pri opravilu v ozadju poiščite obstoječo referenco in njeno stanje, namesto da bi kot preizkus povezljivosti ustvarili novo operacijo.

Če je rezultat tam, ste končali in napaka pripada poti odgovora, ne pisanju. Če ga ni, ohranite možnost, da ga aplikacija še ni potrdila: opravilo v čakalni vrsti, zakasnjen pogled za branje ali replika, ki zaostaja, lahko za nekaj časa skrijejo uspešno pisanje.

Preden naredite sklep, mu dajte določen drugi pogled in zabeležite čas obeh preverjanj. Dve preverjanji, oddaljeni dvajset sekund, sta veliko šibkejši dokaz kot dve, oddaljeni deset minut.

Presodite, ali je druga oddaja varna

Odgovor je odvisen od operacije, ne od vaše potrpežljivosti. HTTP ločuje metode, ki jih je mogoče ponoviti z enakim predvidenim učinkom, od tistih, ki jih ni mogoče, in odsvetuje samodejno ponavljanje druge vrste, razen če je znano, da to semantika dovoljuje. Ustvarjanje komentarja, oddaja naročila in pošiljanje plačila običajno spadajo v drugo skupino, zato drugi na videz uspešni klik ne pove ničesar o prvem.

Če vzdržujete odjemalca, uporabite mehanizem za ponovni poskus ali idempotentnost, ki ga dokumentira API, in ga privežite na isto logično operacijo, namesto da bi za vsak poskus ustvarili nov ključ. Identifikator zahteve, uporabljen za sledenje, ni ključ za zatiranje dvojnikov, razen če strežnik z njim tako ravna.

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

Ključ pomaga le, če ga storitev shrani ob operaciji in pri ponovitvi vrne prvotni rezultat. To vedenje preizkusite na preskusni končni točki, preden se v proizvodnji zanesete nanj.

Zberite dokaze, preden znova pritisnete karkoli

Shranite omrežni vnos, ne posnetka zaslona z napako. Metoda zahteve, URL, odgovor ali časovna omejitev in čas dogodka so tisto, kar lahko skrbnik poveže z zapisi aplikacije. Vnos izvozite ali kopirajte kot ukaz le, če nato iz kopije odstranite piškotke, glave za avtorizacijo in vso zasebno vsebino. Pustite svojo sejo nedotaknjeno in nikoli ne predvajajte ujete zahteve s poverilnicami kot bližnjice.

Lastnika storitve vprašajte eno konkretno vprašanje: ali je operacija s to vsebino ob tem času uspela in ali zanjo obstaja referenca? To vprašanje ima odgovor, medtem ko "se je stran pokvarila" ničesar nima.

Smisel vaje je ugotoviti, da se je dejanje zgodilo natanko enkrat. Sporočilo o napaki, ki ga lahko zaprete, ni isto kot zapis, ki mu lahko zaupate, in slednjega potrebujete, preden pošljete karkoli drugega.