Gemte det timede indsendte arbejde sig faktisk?

Knappen spinner, fanen viser en fejl, og den formular, du brugte ti minutter på at udfylde, er væk. Det, du ikke ved, er, om skrivningen nåede frem, før forbindelsen døde. At behandle det ukendte som en fejl er måden, hvorpå dobbelte kommentarer, dobbelte ordrer og gentagne supportbilletter opstår.

Gendan i fast rækkefølge: behold teksten, find resultatet, og afgør først derefter, om en anden indsendelse er tilladt.

Start med teksten og tidsstemplet

Kopiér indholdet ud af siden, før du rører noget andet, inklusive enhver kladde, som browseren stadig holder i feltet. Skriv tidspunktet ned, den side du var på, og den handling du udførte, fordi netop disse tre detaljer gør resten af undersøgelsen mulig. Hvis fanen stadig er åben, så lad den stå åben, indtil du har læst netværksposten. At gemme teksten koster intet, og at miste den koster hele opgaven.

Adskil derefter de to fejlformer, du faktisk kan observere. En forbindelse, der faldt midt i anmodningen, og en server, der svarede med en fejl, ser forskellige ud i netværkspanelet, og kun den anden fortæller noget om programmets beslutning.

Søg resultatet i programmets egen visning

Genindlæs den læsevisning, der ville vise resultatet: kommentarlisten, ordrehistorikken, billetkøen eller den post, du redigerede. Match på konto, destination, tid og indhold i stedet for på den nyeste post, fordi en anden kan have skrevet efter dig. For et baggrundsjob skal du slå den eksisterende reference og dens status op i stedet for at oprette en ny operation som forbindelsestest.

Hvis resultatet er der, er du færdig, og fejlen hører til svarvejen, ikke skrivningen. Hvis det ikke er der, så hold muligheden åben for, at programmet endnu ikke har committet det: et job i kø, en forsinket læsevisning eller en bagefter løbende replika kan skjule en vellykket skrivning et stykke tid.

Giv det et defineret andet kig, før du drager en konklusion, og noter tidspunktet for begge kontroller. To kontroller med tyve sekunders mellemrum er meget svagere bevis end to kontroller med ti minutters mellemrum.

Afgør, om en anden indsendelse er sikker

Svaret afhænger af operationen, ikke af din tålmodighed. HTTP skelner mellem metoder, der kan gentages med samme tilsigtede effekt, og dem, der ikke kan, og fraråder automatiske gentagelser af den anden slags, medmindre semantikken vides at tillade det. At oprette en kommentar, afgive en ordre og sende en betaling hører normalt til den anden gruppe, og derfor siger et andet succesfuldt udseende klik intet om det første.

Hvis du vedligeholder klienten, brug den retry- eller idempotensmekanisme, som API’et dokumenterer, og knyt den til den samme logiske operation i stedet for at generere en ny nøgle for hvert forsøg. Et anmodnings-id brugt til sporing er ikke en nøgle til at undertrykke dubletter, medmindre serveren behandler det som sådan.

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øglen hjælper kun, hvis tjenesten gemmer den på operationen og returnerer det oprindelige resultat ved en gentagelse. Test den adfærd på et staging-endpoint, før du stoler på den i produktion.

Saml beviser, før du trykker på noget igen

Behold netværksposten i stedet for et skærmbillede af fejlen. Anmodningsmetoden, URL’en, svaret eller timeoutet og det tidspunkt, det skete på, er det, en administrator kan korrelere med programmets registreringer. Eksportér eller kopiér posten som en kommando, kun hvis du derefter fjerner cookies, autorisationsheadere og ethvert privat indhold fra kopien. Lad din egen session være intakt, og afspil aldrig en opfanget anmodning med legitimationsoplysninger som en genvej.

Stil tjenesteejeren ét konkret spørgsmål: lykkedes operationen med dette indhold på dette tidspunkt, og findes der en reference til den? Det spørgsmål har et svar, mens "gik siden i stykker" ikke har.

Pointen med øvelsen er at fastslå, at handlingen skete præcis én gang. En fejlmeddelelse, du kan afvise, er ikke det samme som en registrering, du kan stole på, og den anden er det, du har brug for, før du indsender noget som helst andet.