IP Sorguları İçin Pratik API Entegrasyon Kontrol Listesi
Timeout ayarları, cache stratejisi, fail-open politikası, header ayrıştırma ve anahtar güvenliği… Bir IP intelligence entegrasyonunun prod ortamında ayakta kalıp kalmayacağını belirleyen mühendislik detayları.
Bir IP intelligence çağrısı eklemek on dakikalık iştir; asıl mesele sonraki altı ay boyunca karşınıza çıkacak uç senaryolardır. Yeni bir entegrasyonun geçmesini isteyeceğimiz kontrol listesi şöyle.
1. İstemci adresini doğru alın
Her şeyden önce, doğru IP adresini sorguladığınızdan emin olun. Load balancer veya CDN arkasında çalışıyorsanız remoteAddr çoğu zaman sizin kendi proxy’nizi gösterir. Bu yüzden forwarded zincirini okumanız gerekir. Ancak burada da yalnızca kontrolünüzde olan hop’lara güvenmeli, kolayca spoof edilebilen en soldaki değer yerine sağdan başlayarak ilk güvenilmeyen girdiyi dikkate almalısınız. Yanlış adresi sorgulamak, hiç sorgulamamaktan daha kötüdür; çünkü sonuç sanki güvenilir bir kararmış gibi görünür.
IPv6’yı da doğru ele alın. Köşeli parantez içindeki adres formatları ve IPv4-mapped notasyon buna dahil.
2. Sert bir timeout belirleyin
Bir zaman bütçesi seçin — signup akışları için 300–800 ms çoğu durumda makul bir aralıktır — ve bunu istemci tarafında mutlaka uygulayın. Takılı kalan bir risk kontrolü, güvenlik özelliğini kolayca kesintiye dönüştürür.
3. Her akış için fail-open mı fail-closed mı karar verin
Bunu her çağrı noktası için açıkça yazılı hale getirin:
- Signup / login → fail open. Bir bağımlılık yavaşladı diye tüm kullanıcı tabanınızı dışarıda bırakmayın.
- Payout veya withdrawal → fail closed uygulayın ya da manuel inceleme kuyruğuna alın. Para çıkışı söz konusuysa gecikme çoğu zaman kabul edilebilir bir bedeldir.
Tüm uygulama için tek bir varsayılan politika belirlemek, ekipleri ya kesintiye ya da finansal kayba götüren klasik hatalardan biridir.
4. Cache kullanın
Aynı adres birkaç dakika içinde size tekrar tekrar gelebilir. Sonuçları mantıklı bir süre boyunca cache’leyin — başlangıç için bir saat iyi bir değerdir — ve anahtar olarak adresi kullanın. Bu yaklaşım aynı anda latency’yi, maliyeti ve sağlayıcı üzerindeki yükü azaltır. TTL değerini yapılandırılabilir tutun; bir incident sırasında kısaltabilir, trafik sıçradığında uzatabilirsiniz.
5. Mümkünse sorguyu kritik yolun dışına alın
Her kontrolün kullanıcı yanıtını bloklaması gerekmez. Analytics temizliği, log zenginleştirme ve sonradan inceleme gibi işler için adresi kuyruğa atıp asenkron olarak zenginleştirin. Senkron çağrıları yalnızca o anda vermeniz gereken kararlar için saklayın.
6. Olumsuz yanıtları ele alın
Hepsini listeleyin ve test edin: rate limit, geçersiz anahtar, bilinmeyen adres, private veya reserved aralık, hatalı formatta input. Her biri kodunuzda tanımlı bir sonuca bağlanmalı; request handler içinde kontrolsüz exception’a dönüşmemeli.
Private aralıklar ayrıca önemlidir. 10.x, 192.168.x, 127.0.0.1 ve benzerleri geliştirme ortamında ve yanlış yapılandırılmış proxy zincirlerinde karşınıza çıkar. Bunları API çağrısı yapmadan önce kısa devreye alın.
7. Anahtarı koruyun
API key her zaman sunucu tarafı konfigürasyonda durmalı; browser JavaScript içine veya mobil uygulama paketine asla gömülmemeli. İstemciye gönderilen her şey artık herkese açıktır. Ekip değişikliklerinde anahtarları rotate edin ve her environment için ayrı anahtar kullanın. Böylece birini iptal etmeniz gerektiğinde tüm sistemi bozmazsınız.
8. Kararla birlikte sonucu da loglayın
Skoru ve flag’leri, aldığınız aksiyonla birlikte saklayın. Aylar sonra “Mart ayında bu siparişi neden reddetmişiz?” diye sorduğunuzda cevap sağlayıcının dashboard’undan yeniden kurgulanmak zorunda kalmamalı; kendi veritabanınızda bulunmalı.
9. Kendi metriklerinizi izleyin
Çağrı latency yüzdeliklerini, hata oranını, cache hit rate’i ve kota tüketimini takip edin. Bu metriklerden herhangi birindeki sessiz kayma, genellikle görünür bir incident’ın habercisidir.
10. Gerçek adreslerle test edin
Test suite’inize bilinen bir datacenter adresi, bilinen bir TOR çıkış noktası, bir residential adres ve bir mobil adres ekleyin. Exact score yerine sınıflandırma üzerinden assertion yazın. Skorlar zamanla değişir; kategoriler daha stabildir.
Bu listeyi bir kez baştan sona uyguladığınızda entegrasyonunuz, onu çıkaran sprint’ten çok daha uzun ömürlü olur.
