Teklif formu yanıt vermiyorsa tekrar göndermek güvenli mi?
Bir ziyaretçi özel üretim teklifi için ölçülerini girer, dosyasını ekler ve gönder düğmesine basar. Ekran dönmeye devam ederken internet bağlantısı kesilir. Talep işletmeye ulaştı mı, yoksa baştan mı gönderilmeli? Bu temsili senaryoda sorun daha güzel bir başarı mesajından büyüktür. Web sitesi, aynı talebin yeniden denenmesini ve gerçekten yeni bir talep açılmasını ayırt edecek bir düzene ihtiyaç duyar.
Önce üç farklı durumu adlandırın
Hazırlanıyor, alındı ve sonuç doğrulanamadı durumlarına ayrı metin hazırlayın. Düğmeye basılması yalnızca işlemi başlatır; ekranda yeşil bir işaret görünmesi, satış ekibinin talebi okuduğunu kanıtlamaz. Sunucu kaydı doğruluyorsa kayıt numarası gösterilebilir. Sunucu yanıtı gelmediyse kesin bir başarısızlık veya başarı ilan etmek yerine durumun henüz doğrulanamadığını anlatın. Kullanıcıya aynı sayfada uygulanabilir tek bir sonraki adım sunun; yazdığı bilgileri gereksiz yere temizlemeyin.
Bir teknik örnekten doğru dersi çıkarın
MDN, aynı POST isteğinin tekrarlanmasının ek etkiler yaratabileceğini açıklar. Stripe belgeleri, aynı işlem anahtarıyla güvenli yeniden denemeye somut bir API örneği verir. Bu, bütün teklif formlarında kendiliğinden bulunan bir özellik değildir. Kendi sitenizde benzer davranış için uygulama ve veritabanı düzeyinde açık bir sözleşme kurulmalıdır; Stripe kullanmanız gerektiği anlamına gelmez.
Aynı talep ile yeni talebi ayırın
Temsili formda ilk gönderim A talebini oluşturur. Bağlantı sorunu sonrası yeniden deneme aynı A kimliğini kullanır; sunucu önceki sonucu döndürebilir. Ziyaretçi ürün adedini değiştirip farklı teklif istiyorsa bunun yeni kayıt mı, mevcut kaydın düzenlemesi mi olacağını kararlaştırın. Aynı anahtarla farklı içeriğin sessizce kabul edilmesini önleyin. Anahtarın saklama süresini, çakışma davranışını ve yeniden deneme sınırını geliştiriciden yazılı isteyin. Anahtarın kendisine e-posta veya telefon yerleştirmeyin.
Düğmenin kilitlenmesi tek başına çözüm değildir
Gönderim sırasında düğmeyi geçici olarak devre dışı bırakmak art arda tıklamayı azaltabilir; yenilenen sayfadan, ikinci sekmeden veya ağ katmanından gelen tekrarları yönetmez. Bekleme göstergesine açıklayıcı bir durum metni eşlik etsin. Uzun bekleme sonunda düğmeyi sonsuza kadar kapalı bırakmayın. Tasarımcı ekrandaki durumları, geliştirici kaydın tekilliğini, işletme ise talebin hangi aşamada ekibe ulaştığını birlikte tanımlasın. Böylece yalnız ön yüzde çalışan sahte bir güven duygusu oluşmaz.
Teyit mesajının kapsamını dürüst tutun
Kayıt oluştuysa talep numarası, kısa bir özet ve bundan sonra ne olacağı görünür olsun. E-postanın ayrıca kuyruğa alınması, gönderilmesi ve alıcıya teslim edilmesi farklı aşamalardır. Bildirim e-postası gecikti diye aynı talebi yeniden yaratmayın. İşletmenin gerçekten sürdürebildiği bir geri dönüş süresi yoksa kesin saat sözü yazmayın. Kullanıcı destek isterse hangi kayıt numarasını paylaşacağını anlasın; numaranın tek başına özel talep içeriğini açmasına izin verilmesin.
Kabul testini tek başarılı denemeyle bitirmeyin
Test ortamında aynı talebi iki kez iletin, sunucu kaydı oluştuktan sonra yanıtı geciktirin ve sonuç sayfasını yenileyin. Her senaryoda kaç iş kaydı ve kaç bildirim üretildiğini kontrol edin. Sonra aynı kişi için gerçekten farklı ikinci bir talep açın; yanlışlıkla engellenmediğini görün. Testlerin gerçek müşterilere e-posta göndermediğinden emin olun. Web tasarım kapsamına bu kabul koşullarını eklemek, mükerrer kayıt sorumluluğunu yayın sonrasına bırakmamanızı sağlar.
Sık sorulan sorular
Aynı e-postadan gelen iki talep her zaman mükerrer midir?
Hayır. Aynı kişi farklı ürün veya işler için başvurabilir. Tekillik kuralı yalnız e-posta adresine dayanırsa geçerli talepleri de engelleyebilir.