Vai tas nokavētais iesniegums tiešām saglabāja tavu darbu?

Poga griežas, cilnē redzama kļūda, un forma, kuru pildīji desmit minūtes, ir pazudusi. Tu nezini, vai rakstīšana nonāca pirms savienojums nomira. Tieši šīs neziņas uztveršana kā neveiksmes ir tas, kā rodas dubultoti komentāri, dubulti pasūtījumi un atkārtotas atbalsta biļetes.

Atjauno noteiktā kārtībā: paturi tekstu, atrodi rezultātu un tikai tad izlem, vai otrs iesniegums ir atļauts.

Sāc ar tekstu un laika zīmi

Nokopē saturu no lapas, pirms aiztiec ko citu, tostarp jebkuru melnrakstu, ko pārlūks vēl tur laukā. Pieraksti laiku, lapu, kurā biji, un veikto darbību, jo tieši šīs trīs detaļas padara iespējamu pārējo izmeklēšanu. Ja cilne vēl ir atvērta, atstāj to atvērtu, līdz izlasīsi tīkla ierakstu. Teksta saglabāšana neko nemaksā, bet tā zaudēšana maksā visu uzdevumu.

Pēc tam atdaliet divus kļūdu veidus, kurus patiešām vari novērot. Savienojums, kas pārtrūka pieprasījuma vidū, un serveris, kas atbildēja ar kļūdu, tīkla panelī izskatās atšķirīgi, un tikai otrais kaut ko pasaka par lietotnes lēmumu.

Meklē rezultātu pašā lietotnes skatā

Pārlādē lasīšanas skatu, kas parādītu rezultātu: komentāru sarakstu, pasūtījumu vēsturi, biļešu rindu vai ierakstu, kuru rediģēji. Salīdzini pēc konta, galamērķa, laika un satura, nevis pēc jaunākā ieraksta, jo kāds cits varēja rakstīt pēc tevis. Fona uzdevumam meklē esošo atsauci un tās statusu, nevis veido jaunu operāciju kā savienojuma testu.

Ja rezultāts ir, esi pabeidzis, un kļūda pieder atbildes ceļam, nevis rakstīšanai. Ja tā nav, paturi iespēju, ka lietotne to vēl nav fiksējusi: rindā esošs uzdevums, aizkavēts lasīšanas skats vai atpalicis replikāts var uz laiku paslēpt veiksmīgu rakstīšanu.

Pirms izdari secinājumu, piešķir tam noteiktu otru skatienu un pieraksti abu pārbaužu laiku. Divas pārbaudes divdesmit sekunžu attālumā ir daudz vājāks pierādījums nekā divas pārbaudes desmit minūšu attālumā.

Izlem, vai otrs iesniegums ir drošs

Atbilde ir atkarīga no operācijas, nevis no tavas pacietības. HTTP atdala metodes, kuras var atkārtot ar to pašu paredzēto efektu, no tām, kuras nevar, un iesaka neveikt otrā veida automātisku atkārtošanu, ja vien nav zināms, ka semantika to atļauj. Komentāra izveide, pasūtījuma veikšana un maksājuma nosūtīšana parasti ietilpst otrajā grupā, tāpēc otrs veiksmīgi izskatošs klikšķis neko nepasaka par pirmo.

Ja uzturi klientu, izmanto API dokumentēto atkārtošanas vai idempotences mehānismu un piesaisti to pašai loģiskajai operācijai, nevis ģenerē jaunu atslēgu katram mēģinājumam. Izsekošanai izmantotais pieprasījuma identifikators nav dublikātu nomākšanas atslēga, ja vien serveris to neuzskata par tādu.

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

Atslēga palīdz tikai tad, ja pakalpojums to glabā pie operācijas un atkārtojumā atgriež sākotnējo rezultātu. Pārbaudi šo uzvedību testa galapunktā, pirms paļaujies uz to ražošanā.

Vāc pierādījumus, pirms vēlreiz kaut ko nospied

Saglabā tīkla ierakstu, nevis kļūdas ekrānuzņēmumu. Pieprasījuma metode, URL, atbilde vai taimauts un notikuma laiks ir tas, ko administrators var sasaistīt ar lietotnes ierakstiem. Eksportē vai kopē ierakstu kā komandu tikai tad, ja pēc tam no kopijas noņem sīkfailus, autorizācijas galvenes un jebkuru privātu saturu. Atstāj savu sesiju neskartu un nekad neatkārto pārtvertu pieprasījumu ar akreditācijas datiem kā īsceļu.

Pajautā pakalpojuma īpašniekam vienu konkrētu jautājumu: vai operācija ar šo saturu šajā laikā izdevās, un vai tai ir atsauce? Uz šo jautājumu ir atbilde, bet "vai vietne salūza" tās nav.

Šī vingrinājuma jēga ir noskaidrot, ka darbība notika tieši vienu reizi. Kļūdas ziņojums, ko vari aizvērt, nav tas pats, kas ieraksts, kuram vari uzticēties, un tieši otrais tev vajadzīgs, pirms sūti ko citu.