Webhook nedir?
Webhook, bir yazılım sisteminde gerçekleşen belirli olaylara abone olunmasını ve olay oluştuğunda verinin dış bir sunucuya HTTP isteğiyle otomatik iletilmesini sağlayan yöntemdir. Abonelik yalnızca webhook oluşturulurken bir kez yapılır. Veri olay anında gelir; alıcının periyodik olarak sormasına gerek kalmaz.
Olay bildirimi nasıl işler
Webhook oluşturulurken bir adres ve dinlenecek olaylar belirlenir. Olay gerçekleştiğinde kaynak sistem, olayla ilgili veriyi içeren bir HTTP isteğini bu adrese gönderir. Alıcı sunucu isteği alıp işlem yapar; örneğin stok düşürme, müşteriye bildirim veya muhasebe kaydı. Webhook yalnızca tanımlandığı hesap veya uygulama içindeki kaynaklara erişebilir.
Polling ile farkı ve tercih ölçütü
Polling, sistemin belirli aralıklarla API'ye sorgu göndererek yeni veri olup olmadığını kontrol etmesidir. Çok sayıda sipariş veya ürün izlenirken her kayıt için sorgu yapmak API limitlerini hızla tüketebilir. Webhook ise yalnızca olay olduğunda çalışır. Seyrek ve küçük veri ihtiyaçlarında doğrudan API çağrısı yeterli olabilir.
Temsili işletme örneği
Temsili senaryo: Küçük bir giyim mağazası, ödeme sağlayıcısından ödeme onayı bildirimi alacak şekilde kurulmuştur. Müşteri ödemeyi tamamladığında sağlayıcı, sipariş numarasını ve tutarı içeren bir istek gönderir. Mağaza sunucusu isteği alır, siparişi hazırlanıyor durumuna çeker, depo ekibinin etiket listesine kayıt düşer ve müşteriye onay e-postası kuyruğa eklenir. Aynı bildirim ağ sorunu nedeniyle iki kez gelirse, sipariş numarasına göre kontrol yapılmadığında mükerrer etiket oluşabilir.
Webhook ile periyodik sorgu farkı
| Webhook | Periyodik sorgu |
|---|---|
| Veri olay anında gelir | Sonuç sorgu aralığına bağlıdır |
| Tek abonelik yeterlidir | Her kontrol için ayrı istek gerekir |
| Tekrar ve sıra yönetimi alıcıdadır | Yanıt okunup farklar ayrıca bulunur |
Sık karıştırılan nokta
Yaygın yanlış düşünce: Webhook bir kez tanımlandığı için her bildirim mutlaka tek ve gönderildiği sırayla gelir. Doğrusu, ağ hataları nedeniyle aynı olayın tekrar gelebileceği ve bildirimlerin sırasının karışabileceğidir. Alıcı tarafta olay kimliğiyle tekrar kontrolü ve durum bazlı güncelleme yapılmalıdır.
Uygulamada dikkat edilecekler
- Her gelen isteği işlemeden önce gönderenin kimliğini doğrulayan bir kontrol ekleyin ve doğrulanamayan istekleri reddedin.
- Olay kimliğini veritabanında saklayın; aynı kimlik ikinci kez gelirse yeni kayıt oluşturmadan başarılı yanıt verin.
- Sipariş durumunu gelen her bildirimde körlemesine değiştirmek yerine olayın zaman bilgisine bakın ve eski görünen güncellemeleri atlayın.
- Sunucunuzun yanıt süresini ölçün; ağır işlemleri kuyruğa alıp isteğe hızlı yanıt dönün ki gönderen taraf zaman aşımına uğramasın.
Sık sorulan sorular
Webhook gönderimi başarısız olursa sipariş bildirimi kaybolur mu?
Bu, gönderen sistemin yeniden deneme politikasına ve sunucunuzun yanıt durumuna bağlıdır. Kayıp riskini azaltmak için düzenli çalışan bir yedek sorgu süreci ve bildirim kayıtlarının izlenmesi yaygın bir yaklaşımdır. Ayrıntıları kullandığınız sistemin dokümantasyonundan doğrulayın.
Webhook yerine doğrudan API kullanmak ne zaman daha uygundur?
Düşük hacimli ve seyrek ihtiyaçlarda, örneğin ayda birkaç kez bir ürünün fiyatına bakılacaksa API çağrısı daha basit olabilir. Sürekli izlenen çok sayıda kayıt varsa webhook genellikle daha az kaynak tüketir.
Teknik kaynak
Teknik tanım için birincil kaynağa başvurulmuştur. İşletme senaryosu açıklama amacıyla hazırlanmış temsili bir örnektir.
İlgili kavramlar
Kavramdan uygulamaya
İşletmenize uyarlamak için ilgili rehberleri inceleyin.
Chatbot Entegrasyonunda Bilgi Okuma ve İşlem YetkisiCanlı Fiyat Bilgisi İle Sabit Fiyat Metnini AyırmakTüm blog rehberleri