Butang berputar, tab menunjukkan ralat, dan borang yang anda isi selama sepuluh minit telah hilang. Apa yang anda tidak tahu ialah sama ada penulisan itu sampai sebelum sambungan terputus. Menganggap ketidakpastian itu sebagai kegagalan ialah cara komen berganda, pesanan berganda dan tiket sokongan berulang tercipta.

Pulihkan dalam urutan tetap: simpan teks, cari hasilnya, dan hanya selepas itu tentukan sama ada penghantaran kedua dibenarkan.

Mulakan dengan teks dan cap masa

Salin kandungan daripada halaman sebelum anda menyentuh apa-apa lagi, termasuk draf yang masih dipegang pelayar dalam medan. Catat masa, halaman tempat anda berada dan tindakan yang anda lakukan, kerana ketiga-tiga butiran itulah yang membolehkan siasatan selebihnya. Jika tab masih terbuka, biarkan ia terbuka sehingga anda membaca entri rangkaian. Menyimpan teks tidak berharga apa-apa, dan kehilangannya berharga seluruh tugas.

Kemudian asingkan dua bentuk kegagalan yang benar-benar boleh anda perhatikan. Sambungan yang terputus di tengah permintaan dan pelayan yang menjawab dengan ralat kelihatan berbeza dalam panel rangkaian, dan hanya yang kedua memberitahu sesuatu tentang keputusan aplikasi.

Cari hasilnya dalam paparan aplikasi itu sendiri

Muat semula paparan baca yang akan menunjukkan hasilnya: senarai komen, sejarah pesanan, baris gilir tiket atau rekod yang anda sunting. Padankan mengikut akaun, destinasi, masa dan kandungan dan bukan mengikut entri terbaharu, kerana orang lain mungkin menulis selepas anda. Untuk tugas latar belakang, cari rujukan yang sedia ada dan statusnya dan bukannya mencipta operasi baharu sebagai ujian sambungan.

Jika hasilnya ada, anda selesai dan ralat itu milik laluan balasan, bukan laluan penulisan. Jika tiada, kekalkan kemungkinan aplikasi belum mengesahkannya: tugas dalam baris gilir, paparan baca tertunda atau replika yang ketinggalan boleh menyembunyikan penulisan yang berjaya untuk seketika.

Berikan sekali lagi pandangan kedua yang ditetapkan sebelum membuat kesimpulan, dan catat masa kedua-dua semakan. Dua semakan yang terpisah dua puluh saat jauh lebih lemah sebagai bukti daripada dua semakan yang terpisah sepuluh minit.

Tentukan sama ada penghantaran kedua selamat

Jawapannya bergantung pada operasi, bukan pada kesabaran anda. HTTP memisahkan kaedah yang boleh diulang dengan kesan yang dimaksudkan sama daripada yang tidak boleh, dan menasihati supaya tidak mencuba semula secara automatik jenis kedua melainkan semantiknya diketahui membenarkannya. Mencipta komen, membuat pesanan dan menghantar bayaran biasanya dalam kumpulan kedua, sebab itu klik kedua yang kelihatan berjaya tidak berkata apa-apa tentang yang pertama.

Jika anda menyelenggara klien, gunakan mekanisme cubaan semula atau idempotensi yang didokumenkan API, dan kaitkan dengan operasi logik yang sama dan bukannya menjana kunci baharu untuk setiap cubaan. Pengecam permintaan yang digunakan untuk penjejakan bukan kunci penekan pendua melainkan pelayan memperlakukannya sedemikian.

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

Kunci itu hanya membantu jika perkhidmatan menyimpannya bersama operasi dan memulangkan hasil asal pada ulangan. Uji tingkah laku itu di titik akhir pementasan sebelum anda bergantung padanya dalam pengeluaran.

Kumpulkan bukti sebelum menekan apa-apa lagi

Simpan entri rangkaian dan bukannya tangkapan skrin ralat. Kaedah permintaan, URL, balasan atau tamat masa dan masa ia berlaku ialah apa yang pentadbir boleh kaitkan dengan rekod aplikasi. Eksport atau salin entri sebagai arahan hanya jika anda kemudian membuang kuki, pengepala kebenaran dan sebarang kandungan peribadi daripada salinan itu. Biarkan sesi anda sendiri utuh, dan jangan sekali-kali memainkan semula permintaan tertangkap yang membawa kelayakan sebagai jalan pintas.

Tanya pemilik perkhidmatan satu soalan khusus: adakah operasi dengan kandungan ini pada masa ini berjaya, dan adakah rujukannya? Soalan itu mempunyai jawapan, manakala "adakah laman rosak" tidak.

Inti pati latihan ini ialah memastikan tindakan itu berlaku tepat sekali. Mesej ralat yang boleh anda tutup bukan sama dengan rekod yang boleh anda percayai, dan yang kedua itulah yang anda perlukan sebelum menghantar apa-apa lagi.

Artikel berkaitan