Tek teslim varsayımını bırakın
Webhook sağlayıcıları yanıt alamadığında aynı olayı tekrar gönderebilir. Ağ zaman aşımında alıcı işi tamamlamış olsa bile sağlayıcı bunu bilemez. Bu nedenle tasarımı bir olayın birden fazla kez teslim edilebileceği varsayımıyla yapın. Olay kimliğini sağlayıcı ve hesap kapsamıyla birlikte değerlendirin.
İmzayı ham gövde üzerinden doğrulayın
Sağlayıcının imza algoritması ve zaman damgası kurallarını takip edin. JSON'u yeniden oluşturmak ham gövdeyi değiştirebilir ve doğrulamayı bozabilir. Sabit zamanlı karşılaştırma ve gerekiyorsa zaman toleransı kullanın. Anahtarları kaynak kodunda tutmayın; değişimleri ve geçersiz imza denemelerini izleyin.
Kabul ile işleme adımlarını ayırın
Önce geçerli olayı kalıcı olarak kaydedin veya kuyruğa alın. Uzun süren ERP işlemini HTTP isteği içinde bekletmek yeniden gönderime neden olabilir. Erken başarı yanıtı ancak olay güvenilir biçimde kabul edildiyse verilmelidir. Bellekte duran bir görev, süreç yeniden başladığında kaybolabilir.
Tekrar kontrolünü atomik yapın
Olay kimliğinin daha önce görülüp görülmediğini kontrol edip sonra kayıt eklemek yarış koşuluna açıktır. Kalıcı depoda benzersiz kısıt veya uygun atomik işlem kullanın. Dış sisteme yapılan çağrıda da idempotency anahtarı desteğini değerlendirin. İşleme durumu, sonuç ve hata birbirinden ayrılmalıdır.
Retry, sıralama ve inceleme kuyruğu
Geçici hataları artan bekleme süresiyle yeniden deneyin; kalıcı hataları sonsuz döngüye sokmayın. Olayların sırayla gelmesini garanti kabul etmeyin. Gerektiğinde API'den güncel nesne durumunu çekin. Başarısız olayları inceleme kuyruğunda tutarak yetkili kişinin kontrollü biçimde tekrar işlemesine olanak verin.
Bu akışı kendi sistemlerinize taşımak için.
Mevcut yazılımlarınızı ve bağlantı ihtiyacınızı birlikte değerlendirelim.
İhtiyacınızı anlatın ↗