A e ruajti vërtet punën tuaj ai dërgim që skadoi?

Butoni rrotullohet, skeda tregon një gabim dhe formulari që e plotësuat për dhjetë minuta ka humbur. Ajo që nuk e dini është nëse shkrimi mbërriti përpara se lidhja të vdiste. Trajtimi i asaj të panjohure si dështim është mënyra se si krijohen komente të dyfishta, porosi të dyfishta dhe kërkesa mbështetjeje të përsëritura.

Rikuperoni në një rend fiks: mbani tekstin, gjeni rezultatin dhe vetëm pastaj vendosni nëse lejohet një dërgim i dytë.

Filloni me tekstin dhe me vulën kohore

Kopjoni përmbajtjen nga faqja përpara se të prekni çdo gjë tjetër, përfshirë çdo draft që shfletuesi ende e mban në fushë. Shkruani orën, faqen ku ishit dhe veprimin që bëtë, sepse pikërisht këto tre detaje e bëjnë të mundur pjesën tjetër të hetimit. Nëse skeda është ende e hapur, lëreni të hapur derisa të lexoni hyrjen e rrjetit. Ruajtja e tekstit nuk kushton asgjë, dhe humbja e tij kushton të gjithë detyrën.

Pastaj ndani dy format e dështimit që vërtet mund t'i vëzhgoni. Një lidhje që ra në mes të kërkesës dhe një server që u përgjigj me gabim duken ndryshe në panelin e rrjetit, dhe vetëm i dyti ju thotë diçka për vendimin e aplikacionit.

Kërkoni rezultatin në pamjen e vetë aplikacionit

Ringarkoni pamjen e leximit që do të tregonte rezultatin: listën e komenteve, historikun e porosive, radhën e kërkesave ose regjistrin që po redaktonit. Krahasoni sipas llogarisë, destinacionit, orës dhe përmbajtjes dhe jo sipas hyrjes më të re, sepse dikush tjetër mund të ketë shkruar pas jush. Për një detyrë në sfond, kërkoni referencën ekzistuese dhe statusin e saj në vend që të krijoni një operacion të ri si test lidhjeje.

Nëse rezultati është aty, keni mbaruar dhe gabimi i përket rrugës së përgjigjes, jo shkrimit. Nëse nuk është, mbani mundësinë që aplikacioni ende nuk e ka konfirmuar: një detyrë në radhë, një pamje leximi e vonuar ose një replikë që mbetet pas mund të fshehin për një kohë një shkrim të suksesshëm.

Jepini një vështrim të dytë të caktuar përpara se të nxirrni përfundim dhe shënoni orën e të dy kontrolleve. Dy kontrolle të ndara me njëzet sekonda janë provë shumë më e dobët sesa dy kontrolle të ndara me dhjetë minuta.

Vendosni nëse një dërgim i dytë është i sigurt

Përgjigja varet nga operacioni, jo nga durimi juaj. HTTP ndan metodat që mund të përsëriten me të njëjtin efekt të synuar nga ato që nuk mund të përsëriten, dhe këshillon kundër përpjekjeve automatike të llojit të dytë, përveç nëse dihet se semantika e lejon. Krijimi i një komenti, dhënia e një porosie dhe dërgimi i një pagese zakonisht janë në grupin e dytë, prandaj një klikim i dytë që duket i suksesshëm nuk thotë asgjë për të parin.

Nëse mirëmbani klientin, përdorni mekanizmin e përpjekjes së re ose të idempotencës që dokumenton API, dhe lidheni me të njëjtin operacion logjik në vend që të gjeneroni një çelës të re për çdo përpjekje. Një identifikues kërkese i përdorur për gjurmim nuk është çelës për shtypjen e dublikatave, përveç nëse serveri e trajton si të tillë.

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

Çelësi ndihmon vetëm nëse shërbimi e ruan bashkë me operacionin dhe kthen rezultatin origjinal në një përsëritje. Testoni atë sjellje në një pikë fundore provë përpara se të mbështeteni në të në prodhim.

Mblidhni prova përpara se të shtypni përsëri diçka

Ruani hyrjen e rrjetit në vend të një pamjeje ekrani të gabimit. Metoda e kërkesës, URL-ja, përgjigja ose koha e skadimit dhe ora kur ndodhi janë ajo që një administrator mund ta korrelojë me regjistrat e aplikacionit. Eksportojeni ose kopjoni hyrjen si komandë vetëm nëse pastaj hiqni nga kopja cookie-t, titujt e autorizimit dhe çdo përmbajtje private. Lëreni sesionin tuaj të paprekur dhe mos riprodhoni kurrë një kërkesë të kapur me kredenciale si shkurtore.

Pyetni pronarin e shërbimit një pyetje konkrete: a pati sukses operacioni me këtë përmbajtje në këtë orë, dhe a ekziston një referencë për të? Ajo pyetje ka përgjigje, ndërsa "a u prish faqja" nuk ka.

Qëllimi i ushtrimit është të vërtetohet se veprimi ndodhi saktësisht një herë. Një mesazh gabimi që mund ta mbyllni nuk është e njëjta gjë me një regjistër të cilit mund t'i besoni, dhe i dyti është ai që ju nevojitet përpara se të dërgoni çdo gjë tjetër.