Бутонът се върти, разделът показва грешка и формулярът, който попълвахте десет минути, е изчезнал. Не знаете дали записът е стигнал, преди връзката да прекъсне. Третирането на тази неизвестност като провал е начинът, по който се създават дублирани коментари, двойни поръчки и повторни заявки до поддръжката.

Възстановявайте в строг ред: запазете текста, намерете резултата и едва тогава решете дали е разрешено второ изпращане.

Започнете с текста и часа

Копирайте съдържанието от страницата, преди да пипнете каквото и да е друго, включително черновата, която браузърът още пази в полето. Запишете часа, страницата, на която сте били, и действието, което сте извършили, защото тези три подробности правят възможно останалото разследване. Ако разделът е още отворен, оставете го отворен, докато прочетете записа в мрежата. Запазването на текста не струва нищо, а загубата му струва цялата задача.

След това разделете двата вида отказ, които наистина можете да наблюдавате. Връзка, прекъснала по средата на заявката, и сървър, отговорил с грешка, изглеждат различно в мрежовия панел и само второто ви казва нещо за решението на приложението.

Търсете резултата в собствената изглед на приложението

Презаредете изгледа за четене, който би показал резултата: списъка с коментари, историята на поръчките, опашката със заявки или записа, който редактирахте. Съпоставяйте по акаунт, дестинация, време и съдържание, а не по най-новия запис, защото някой друг може да е писал след вас. За фонова задача потърсете съществуващата референция и нейния статус, вместо да създавате нова операция като тест за свързаност.

Ако резултатът е там, готово е и грешката принадлежи на пътя на отговора, а не на записа. Ако не е там, запазете възможността приложението още да не го е фиксирало: чакаща задача, закъснял изглед за четене или изоставаща реплика могат да скрият успешен запис за известно време.

Дайте му определен втори поглед, преди да правите извод, и отбележете часа на двете проверки. Две проверки на двадесет секунди разстояние са много по-слабо доказателство от две проверки на десет минути разстояние.

Решете дали второ изпращане е безопасно

Отговорът зависи от операцията, не от търпението ви. HTTP разделя методите, които могат да се повторят със същия желан ефект, от тези, които не могат, и съветва срещу автоматични повторения от втория вид, освен ако не се знае, че семантиката го позволява. Създаването на коментар, подаването на поръчка и изпращането на плащане обикновено са във втората група, затова едно второ успешно изглеждащо кликване не казва нищо за първото.

Ако поддържате клиента, използвайте механизма за повторение или идемпотентност, който API документира, и го свържете със същата логическа операция, вместо да генерирате нов ключ за всеки опит. Идентификаторът на заявка, използван за проследяване, не е ключ за потискане на дубликати, освен ако сървърът не го третира като такъв.

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

Ключът помага само ако услугата го съхранява към операцията и връща първоначалния резултат при повторение. Проверете това поведение на тестова крайна точка, преди да разчитате на него в производство.

Съберете доказателства, преди да натиснете отново

Пазете мрежовия запис, а не екранна снимка на грешката. Методът на заявката, URL адресът, отговорът или изтичането и часът, в който се е случило, са това, което администраторът може да съпостави със записите на приложението. Експортирайте или копирайте записа като команда само ако после премахнете от копието бисквитките, заглавките за оторизация и всяко лично съдържание. Оставете собствената си сесия непокътната и никога не възпроизвеждайте прихваната заявка с идентификационни данни като пряк път.

Попитайте собственика на услугата един конкретен въпрос: успя ли операцията с това съдържание в този час и има ли референция за нея? Този въпрос има отговор, а "счупи ли се сайтът" няма.

Смисълът на упражнението е да се установи, че действието е станало точно веднъж. Съобщение за грешка, което можете да затворите, не е същото като запис, на който можете да се доверите, и второто е това, което ви трябва, преди да изпратите нещо друго.

Подобни статии