Zaman aşımına uğrayan o gönderim işinizi gerçekten kaydetti mi?

Düğme dönüyor, sekme hata gösteriyor ve on dakika boyunca doldurduğunuz form kayboldu. Bilmediğiniz şey, yazmanın bağlantı kopmadan önce ulaşıp ulaşmadığı. Bu bilinmeyeni başarısızlık olarak ele almak, yinelenen yorumların, çift siparişlerin ve tekrar eden destek taleplerinin ortaya çıkma biçimidir.

Sabit bir sırayla kurtarın: metni saklayın, sonucu bulun ve ancak o zaman ikinci gönderime izin verilip verilmediğine karar verin.

Metinle ve zaman damgasıyla başlayın

Başka herhangi bir şeye dokunmadan önce içeriği sayfadan kopyalayın, tarayıcının hâlâ alanda tuttuğu taslak da dahil. Saati, bulunduğunuz sayfayı ve yaptığınız eylemi yazın, çünkü araştırmanın geri kalanını mümkün kılan tam olarak bu üç ayrıntıdır. Sekme hâlâ açıksa, ağ kaydını okuyana kadar açık bırakın. Metni kaydetmek hiçbir şeye mal olmaz, onu kaybetmek ise tüm göreve mal olur.

Ardından gerçekten gözlemleyebileceğiniz iki arıza biçimini ayırın. İsteğin ortasında kopan bir bağlantı ile hata ile yanıt veren bir sunucu ağ panelinde farklı görünür ve uygulamanın kararı hakkında bir şey söyleyen yalnızca ikincisidir.

Sonucu uygulamanın kendi görünümünde arayın

Sonucu gösterecek okuma görünümünü yeniden yükleyin: yorum listesi, sipariş geçmişi, talep kuyruğu veya düzenlediğiniz kayıt. En son girdiye göre değil, hesap, hedef, saat ve içeriğe göre eşleştirin, çünkü sizden sonra başka biri yazmış olabilir. Arka plan işi için, bağlantı testi olarak yeni bir işlem oluşturmak yerine mevcut referansı ve durumunu arayın.

Sonuç oradaysa bitmişsinizdir ve hata yazmaya değil yanıt yoluna aittir. Değilse, uygulamanın henüz onaylamamış olma olasılığını koruyun: kuyruktaki bir iş, gecikmiş bir okuma görünümü veya geride kalan bir replika başarılı bir yazmayı bir süre gizleyebilir.

Bir sonuca varmadan önce ona belirli bir ikinci bakış verin ve iki kontrolün saatini not edin. Yirmi saniye arayla yapılan iki kontrol, on dakika arayla yapılan iki kontrolden çok daha zayıf bir kanıttır.

İkinci gönderimin güvenli olup olmadığına karar verin

Yanıt işleme bağlıdır, sabrınıza değil. HTTP aynı amaçlanan etkiyle yinelenebilen yöntemleri yinelenemeyenlerden ayırır ve ikinci türün otomatik olarak yinelenmesini, anlambilimin buna izin verdiği bilinmiyorsa önermez. Yorum oluşturmak, sipariş vermek ve ödeme göndermek genellikle ikinci gruptadır, bu yüzden başarılı görünen ikinci bir tıklama birincisi hakkında hiçbir şey söylemez.

İstemciyi siz sürdürüyorsanız, API'nin belgelediği yeniden deneme veya idempotluk mekanizmasını kullanın ve her deneme için yeni bir anahtar üretmek yerine onu aynı mantıksal işleme bağlayın. İzleme için kullanılan istek tanımlayıcısı, sunucu onu öyle ele almadıkça yinelenenleri bastırma anahtarı değildir.

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

Anahtar yalnızca hizmet onu işlemle birlikte saklar ve yinelemede özgün sonucu döndürürse yardımcı olur. Üretimde ona güvenmeden önce bu davranışı bir test uç noktasında sınayın.

Yeniden bir şeye basmadan önce kanıt toplayın

Hatanın ekran görüntüsü yerine ağ kaydını saklayın. İstek yöntemi, URL, yanıt veya zaman aşımı ve bunun gerçekleştiği saat, bir yöneticinin uygulama kayıtlarıyla ilişkilendirebileceği şeylerdir. Kaydı yalnızca ardından kopyadan çerezleri, yetkilendirme başlıklarını ve özel içeriği kaldırırsanız komut olarak dışa aktarın veya kopyalayın. Kendi oturumunuzu bozmayın ve ele geçirilmiş kimlik bilgisi taşıyan bir isteği asla kısayol olarak yeniden oynatmayın.

Hizmet sahibine tek bir somut soru sorun: bu içerikle bu saatte işlem başarılı oldu mu ve bunun için bir referans var mı? O sorunun yanıtı vardır, "site bozuldu mu" sorusunun ise yoktur.

Bu alıştırmanın amacı, eylemin tam olarak bir kez gerçekleştiğini ortaya koymaktır. Kapatabildiğiniz bir hata mesajı, güvenebileceğiniz bir kayıtla aynı şey değildir ve başka bir şey göndermeden önce ihtiyacınız olan ikincisidir.