Lagret den tidsavbrutte innsendingen arbeidet ditt?

Knappen spinner, fanen viser en feil, og skjemaet du brukte ti minutter på å fylle ut er borte. Det du ikke vet, er om skrivingen nådde frem før forbindelsen døde. Å behandle det ukjente som en feil er måten doble kommentarer, doble bestillinger og gjentatte supporthenvendelser oppstår på.

Gjenopprett i fast rekkefølge: behold teksten, finn resultatet, og avgjør først da om en andre innsending er tillatt.

Start med teksten og tidsstempelet

Kopier innholdet ut av siden før du rører noe annet, også utkastet nettleseren fortsatt holder i feltet. Skriv ned klokkeslettet, siden du var på og handlingen du utførte, fordi nettopp disse tre detaljene gjør resten av undersøkelsen mulig. Hvis fanen fortsatt er åpen, la den stå åpen til du har lest nettverksoppføringen. Å lagre teksten koster ingenting, og å miste den koster hele oppgaven.

Skill så de to feilformene du faktisk kan observere. En forbindelse som falt midt i forespørselen og en server som svarte med en feil ser ulike ut i nettverkspanelet, og bare den andre sier noe om applikasjonens beslutning.

Se etter resultatet i appens egen visning

Last inn lesevisningen som ville vise resultatet på nytt: kommentarlisten, ordrehistorikken, sakskøen eller posten du redigerte. Sammenlign på konto, mål, tid og innhold i stedet for på den nyeste oppføringen, fordi noen andre kan ha skrevet etter deg. For en bakgrunnsjobb, slå opp den eksisterende referansen og statusen dens i stedet for å opprette en ny operasjon som tilkoblingstest.

Hvis resultatet er der, er du ferdig, og feilen hører til svarveien og ikke skrivingen. Hvis det ikke er der, hold muligheten åpen for at applikasjonen ennå ikke har festet det: en jobb i kø, en forsinket lesevisning eller en replika som henger etter kan skjule en vellykket skriving en stund.

Gi det et definert andre blikk før du trekker en konklusjon, og noter tidspunktet for begge kontrollene. To kontroller med tjue sekunders mellomrom er mye svakere bevis enn to kontroller med ti minutters mellomrom.

Avgjør om en andre innsending er trygg

Svaret avhenger av operasjonen, ikke av tålmodigheten din. HTTP skiller metoder som kan gjentas med samme tiltenkte effekt fra dem som ikke kan, og fraråder automatiske gjentakelser av den andre typen med mindre semantikken er kjent for å tillate det. Å opprette en kommentar, legge inn en bestilling og sende en betaling hører vanligvis til den andre gruppen, og derfor sier et andre vellykket utseende klikk ingenting om det første.

Hvis du vedlikeholder klienten, bruk retry- eller idempotensmekanismen som API-et dokumenterer, og knytt den til den samme logiske operasjonen i stedet for å generere en ny nøkkel for hvert forsøk. En forespørselsidentifikator brukt til sporing er ikke en nøkkel for å undertrykke duplikater med mindre serveren behandler den som det.

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

Nøkkelen hjelper bare hvis tjenesten lagrer den mot operasjonen og returnerer det opprinnelige resultatet ved en gjentakelse. Test den oppførselen på et staging-endepunkt før du stoler på den i produksjon.

Sikre bevis før du trykker på noe igjen

Behold nettverksoppføringen i stedet for et skjermbilde av feilen. Forespørselsmetoden, URL-en, svaret eller tidsavbruddet og tidspunktet det skjedde på er det en administrator kan korrelere med applikasjonens registreringer. Eksporter eller kopier oppføringen som en kommando bare hvis du deretter fjerner informasjonskapsler, autorisasjonsheadere og alt privat innhold fra kopien. La din egen økt være intakt, og spill aldri av en fanget forespørsel med påloggingsdata som en snarvei.

Spør tjenesteeieren ett konkret spørsmål: lyktes operasjonen med dette innholdet på dette tidspunktet, og finnes det en referanse for den? Det spørsmålet har et svar, mens "gikk siden i stykker" ikke har det.

Poenget med øvelsen er å fastslå at handlingen skjedde nøyaktig én gang. En feilmelding du kan lukke er ikke det samme som en registrering du kan stole på, og den andre er det du trenger før du sender inn noe annet.