La butono turniĝas, la langeto montras eraron, kaj la formularo, kiun vi plenigis dum dek minutoj, malaperis. Kion vi ne scias, estas ĉu la skribo alvenis antaŭ ol la konekto mortis. Trakti tiun nekonaton kiel malsukceson estas la maniero, kiel ekestas duoblaj komentoj, duoblaj mendoj kaj ripetaj subtenaj biletoj.

Riparu laŭ fiksa ordo: konservu la tekston, trovu la rezulton, kaj nur poste decidi ĉu dua sendado estas permesata.

Komencu per la teksto kaj la tempmarko

Kopiu la enhavon el la paĝo antaŭ ol vi tuŝos ion ajn alian, inkluzive de ajna malneto, kiun la retumilo ankoraŭ tenas en la kampo. Notu la tempon, la paĝon, sur kiu vi estis, kaj la agon, kiun vi faris, ĉar ĝuste tiuj tri detaloj ebligas la reston de la enketo. Se la langeto ankoraŭ malfermitas, lasu ĝin malfermita ĝis vi legos la retan enskribon. Konservi la tekston kostas nenion, kaj perdi ĝin kostas la tutan taskon.

Poste apartigu la du formojn de malsukceso, kiujn vi povas efektive observi. Konekto, kiu rompiĝis meze de la peto, kaj servilo, kiu respondis per eraro, aspektas malsame en la reta panelo, kaj nur la dua diras ion pri la decido de la aplikaĵo.

Serĉu la rezulton en la propra vidmaniero de la aplikaĵo

Reŝargu la legvidon, kiu montrus la rezulton: la komentliston, la mendohistorion, la biletan vicon aŭ la rikordon, kiun vi redaktis. Kongruigu laŭ konto, celloko, tempo kaj enhavo anstataŭ laŭ la plej lasta enskribo, ĉar iu alia eble skribis post vi. Por fona tasko, serĉu la ekzistantan referencon kaj ĝian staton anstataŭ krei novan operacion kiel konektecan teston.

Se la rezulto estas tie, vi finis, kaj la eraro apartenas al la responda vojo, ne al la skribo. Se ĝi ne estas tie, tenu la eblecon, ke la aplikaĵo ankoraŭ ne fiksigis ĝin: vicoigita tasko, malfrua legvido aŭ malfruiĝanta repliko povas kaŝi sukcesan skribon dum iom da tempo.

Donu al ĝi difinitan duan rigardon antaŭ ol konkludi, kaj notu la tempon de ambaŭ kontroloj. Du kontroloj dudek sekundojn dise estas multe pli malforta pruvo ol du kontroloj dek minutojn dise.

Decidu, ĉu dua sendado estas sekura

La respondo dependas de la operacio, ne de via pacienco. HTTP apartigas metodojn, kiujn oni povas ripeti kun la sama celata efiko, de tiuj, kiujn oni ne povas, kaj konsilas kontraŭ aŭtomataj ripetoj de la dua speco, krom se oni scias, ke la semantiko permesas tion. Krei komenton, fari mendon kaj sendi pagon kutime apartenas al la dua grupo, tial dua sukcesa ŝajna klako diras nenion pri la unua.

Se vi prizorgas la klienton, uzu la ripetan aŭ idempotencan mekanismon, kiun la API dokumentas, kaj ligi ĝin al la sama logika operacio anstataŭ generi novan ŝlosilon por ĉiu provo. Petidentigilo uzata por spurado ne estas ŝlosilo por subpremi duplikatojn, krom se la servilo traktas ĝin tiel.

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

La ŝlosilo helpas nur se la servo konservas ĝin ĉe la operacio kaj redonas la originan rezulton ĉe ripeto. Testu tiun konduton ĉe proviza finpunkto antaŭ ol fidi ĝin en produktaĵo.

Kolektu pruvojn antaŭ ol denove premu ion

Konservu la retan enskribon anstataŭ ekrankopion de la eraro. La petspeco, la URL, la respondo aŭ la limtempo, kaj la tempo kiam ĝi okazis, estas tio, kion administranto povas kunligi kun la rikordoj de la aplikaĵo. Eksportu aŭ kopiu la enskribon kiel komandon nur se vi tiam forigos el la kopio kuketojn, aŭtorigajn kapliniojn kaj ajnan privatan enhavon. Lasu vian propran seancon netuŝita, kaj neniam reludu kaptitan peton kun legitimiloj kiel fuŝsolvon.

Demandu la posedanton de la servo unu specifan demandon: ĉu la operacio kun tiu ĉi enhavo je tiu ĉi tempo sukcesis, kaj ĉu ekzistas referenco por ĝi? Tiu demando havas respondon, dum "ĉu la retejo rompiĝis" ne havas.

La senco de la ekzerco estas konstati, ke la ago okazis precize unufoje. Erarmesaĝo, kiun vi povas forigi, ne samas kiel rikordo, kiun vi povas fidi, kaj la dua estas tio, kion vi bezonas antaŭ ol sendi ion alian.

Rilataj artikoloj