Webhook Nedir? Sistemleri Gerçek Zamanlı Konuşturmanın Yolu

İki sistemin birbiriyle konuşması gerektiğinde akla gelen ilk yöntem, birinin diğerine sürekli "yeni bir şey var mı?" diye sormasıdır. Bu yaklaşım işe yarar ama verimsizdir; çoğu zaman cevap "hayır" olur ve boşa gidip gelmelerle hem kaynak hem zaman harcanır. Webhook, bu ilişkiyi tersine çevirir: sürekli sormak yerine, olay gerçekleştiğinde haber almayı sağlar. Kısacası webhook, sistemlerin birbirine "bir şey olduğunda seni ararım" demesidir.

Polling ile Webhook Arasındaki Fark

Bu iki yaklaşımı bir kapıcı benzetmesiyle anlamak kolaydır. Polling (sürekli sorgulama) yönteminde, kargonuzun gelip gelmediğini öğrenmek için her beş dakikada bir kapıya çıkıp bakarsınız. Çoğu seferinde kapıda kimse olmaz; boşuna yorulursunuz. Webhook yönteminde ise zile bir sensör takarsınız; kargo geldiğinde zil çalar ve tam o anda haberdar olursunuz. Aradaki fark hem verimlilik hem de hızdır.

• Polling: İstemci belirli aralıklarla sunucuya sorar. Basittir ama gecikmelidir ve boşa istek üretir.
• Webhook: Sunucu, olay olduğunda istemcinin belirttiği adrese anında bildirim gönderir. Gerçek zamanlıdır ve verimlidir.

Polling "sürekli sormaktır", webhook ise "olunca haber vermektir". Gerçek zamanlı ihtiyaçlarda ikincisi neredeyse her zaman kazanır.

Webhook Nasıl Çalışır?

Webhook mekanizması aslında oldukça sadedir. Bir sistem (kaynak), belirli bir olay olduğunda, önceden kaydedilmiş bir URL'e HTTP POST isteği gönderir. Bu isteğin gövdesinde olayla ilgili veri bulunur. Alıcı sistem bu isteği karşılar, veriyi işler ve genellikle 200 durum koduyla "aldım" cevabı verir.

Somut bir örnek: bir ödeme sağlayıcısı, müşterinin ödemesi başarıyla tamamlandığında sizin sisteminizdeki bir adrese bildirim gönderir. Böylece siz sürekli "ödeme geldi mi?" diye sormak zorunda kalmazsınız; ödeme gerçekleştiği anda sipariş durumunu güncellersiniz. Kargo takibi, e-posta teslim durumları, form gönderimleri ve depo stok değişiklikleri de sık kullanılan webhook senaryolarıdır.

Basit Bir Alıcı Örneği

PHP tarafında bir webhook alıcısı, gelen gövdeyi okuyup işler:

$payload = file_get_contents('php://input');
$data = json_decode($payload, true);

if ($data['event'] === 'payment.success') {
    $orderRepo->markPaid($data['order_id']);
}

http_response_code(200);
echo 'OK';

Güvenlik: Gelen İsteğin Gerçek Olduğunu Doğrulamak

Webhook adresiniz internete açıktır; yani teoride herkes o adrese sahte bildirim gönderebilir. Kötü niyetli biri, sahte bir "ödeme başarılı" isteğiyle sizi kandırmaya çalışabilir. Bu yüzden gelen her webhook isteğinin gerçekten beklediğiniz kaynaktan geldiğini doğrulamak zorunludur.

• İmza doğrulama: Çoğu sağlayıcı, isteğe bir gizli anahtarla üretilmiş imza (signature) ekler. Siz bu imzayı kendi anahtarınızla yeniden hesaplayıp karşılaştırırsınız.
• HTTPS zorunluluğu: Webhook adresiniz her zaman şifreli bağlantı üzerinden çalışmalıdır.
• IP kısıtlama: Mümkünse yalnızca sağlayıcının bilinen IP aralıklarından gelen isteklere izin verin.
• Gizli belirteç: URL'e tahmin edilmesi zor bir belirteç ekleyerek adresi gizli tutabilirsiniz.

Bir webhook alıcısı, imzasını doğrulamadığı hiçbir isteğe güvenmemelidir. Açık bir kapı, davetsiz misafirlerin de kapısıdır.

Güvenilirlik: Ya Bildirim Ulaşmazsa?

Ağ her zaman kusursuz değildir. Alıcı sisteminiz o an yavaş olabilir, geçici bir hata verebilir ya da tümüyle erişilemez olabilir. İyi tasarlanmış webhook sistemleri bu ihtimalleri baştan hesaba katar:

1. Yeniden deneme (retry): Gönderici, 200 dışında bir yanıt aldığında bildirimi belirli aralıklarla tekrar gönderir.
2. Idempotency: Aynı bildirim birden fazla kez gelebileceği için, alıcı aynı olayı iki kez işlememelidir. Her olaya benzersiz bir kimlik atanır ve işlenen kimlikler kaydedilir.
3. Hızlı yanıt: Alıcı, ağır işlemleri arka plana atıp bildirime hemen 200 dönmelidir; aksi halde gönderici zaman aşımına düşer.

Özellikle idempotency, ödeme gibi kritik senaryolarda hayatidir. Aynı "ödeme başarılı" bildiriminin iki kez işlenmesi, müşteriye iki ürün göndermek gibi ciddi sonuçlar doğurabilir.

Webhook'u Ne Zaman Tercih Etmeli?

Webhook, olayların anlık öğrenilmesi gereken durumlarda parlar: ödeme onayları, sipariş durumu değişiklikleri, dış servislerden gelen bildirimler. Buna karşılık, veriyi kendi hızınızda toplu olarak çekmek istediğiniz durumlarda klasik API sorguları daha uygundur. Çoğu olgun sistem, ikisini birlikte kullanır; webhook ile anlık haberdar olur, gerekirse API ile ayrıntıyı sorgular.

Berasoft'ta geliştirdiğimiz e-ticaret ve özel yazılım projelerinde, ödeme ve kargo entegrasyonlarını genellikle webhook üzerine kurarız; çünkü müşteri deneyimi gerçek zamanlı bilgiye bağlıdır. Böyle bir gerçek zamanlı entegrasyon kurmayı düşünüyorsanız projenizi konuşalım.

Sonuç

Webhook, modern entegrasyonların sessiz kahramanıdır. Sürekli sorup durmak yerine, olay olduğunda haber almayı sağlayarak hem kaynak tasarrufu hem de gerçek zamanlılık getirir. Ancak bu gücün bedeli, doğru güvenlik ve güvenilirlik önlemlerini almaktır: imza doğrulama, HTTPS, idempotency ve yeniden deneme mantığı olmadan bir webhook sistemi eksik kalır. Bu ilkeleri doğru kurduğunuzda, sistemleriniz birbirine sanki tek bir bütünmüş gibi anlık konuşur.