Kargo takibi, hava durumu, döviz kuru, ödeme doğrulama — modern bir site kendi verisiyle yetinmez, dışarıdan veri çeker. Peki bu bağlantılar paylaşımlı hostingde nasıl davranır?
Bu yazı, dış servis çağrılarının hosting tarafındaki etkilerini ve doğru kurulumu ele alıyor.
Temel Risk: Bekleyen İstek
Bir dış servise bağlandığınızda, sayfanız o servisin hızına bağımlı hâle gelir:
- Ziyaretçi sayfayı ister
- Sunucunuz dış servise bağlanır
- Yanıt bekler
- Bu sırada PHP süreci meşguldür
- Yanıt gelince sayfa oluşturulur
Dördüncü adım kritiktir: dış servis yavaşladığında sizin sayfanız da yavaşlar, servis çöktüğünde sayfanız da çöker.
Paylaşımlı hostingde bunun ek bir maliyeti vardır — bekleyen süreçler eşzamanlı işlem kotanızı doldurur ve diğer ziyaretçiler sıraya girer.
Zaman Aşımı Ayarı
Bu riski sınırlamanın ilk ve en önemli adımı zaman aşımı tanımlamaktır:
- Bağlantı zaman aşımı: Karşı tarafa ulaşma süresi — kısa tutulabilir.
- Toplam zaman aşımı: Yanıtın tamamlanma süresi.
- Varsayılan değerler tehlikelidir. Bazı kütüphanelerde sınırsızdır.
Üçüncü madde en sık yaşanan felaketin kaynağıdır: zaman aşımı tanımlanmamış bir istek, karşı taraf yanıt vermezse dakikalarca asılı kalır ve her ziyaretçi için bu tekrarlanır.
Sonuç, hesabınızın kaynak limitlerini doldurması ve sitenin tamamen erişilemez hâle gelmesidir. Zaman aşımı, isteğe bağlı bir iyileştirme değil zorunlu bir korumadır.
Önbellekleme Stratejisi
Her sayfa görüntülemede dış servise gitmenin gereği yoktur:
| Veri türü | Önbellek süresi |
|---|---|
| Döviz kuru | Saatlik yeterli olabilir |
| Hava durumu | Yarım saat |
| Ürün kataloğu | Günlük veya olay bazlı |
| Kargo takip | Birkaç dakika |
| Ödeme doğrulama | Önbelleklenmez |
Önbellekleme yalnızca hız kazancı değil, dayanıklılık da sağlar: dış servis çöktüğünde elinizde son bilinen veri kalır ve sayfanız boş dönmek yerine biraz eski ama geçerli bir bilgi gösterebilir.
Bu davranışı bilinçli olarak tasarlamak gerekir — önbellek süresi dolduğunda ve yenileme başarısız olduğunda eski veriyi göstermeye devam etmek, çoğu senaryoda hata sayfasından iyidir.
Arka Plana Taşımak
En sağlam yaklaşım, dış servis çağrısını ziyaretçi isteğinden tamamen ayırmaktır:
- Zamanlanmış bir görev düzenli olarak veriyi çeker
- Gelen veriyi veritabanına yazar
- Sayfalar yalnızca veritabanından okur
- Dış servis çökse bile site çalışmaya devam eder
Bu yapı, ziyaretçi deneyimini dış bağımlılıklardan tamamen korur: sayfa yükleme süresi artık dış servisin hızından bağımsızdır.
Yöntem her veri türü için uygun değildir — ödeme doğrulaması gibi anlık işlemler bu şekilde yapılamaz. Ancak katalog, kur, liste türü verilerde ideal çözümdür.
Hosting Tarafındaki Kısıtlar
Paylaşımlı ortamda dış bağlantılar bazı sınırlara tabi olabilir:
- Giden bağlantı kapalı olabilir. Bazı paketlerde kısıtlıdır.
- Belirli portlar engellenebilir.
- Uzak dosya açma kapalı olabilir. Güvenlik gereği.
- Süre limiti çağrıyı kesebilir.
Üçüncü madde yaygın bir güvenlik önlemidir ve doğrudur — uzak dosya açma özelliği kapalıysa, HTTP isteklerini bunun yerine cURL ile yapmalısınız.
cURL zaten daha doğru tercihtir: zaman aşımı, başlık yönetimi ve hata kontrolü açısından çok daha fazla denetim sunar. Bu tür sınırların hangi paketlerde nasıl uygulandığı Linux hosting altyapısı yapılandırmalarına göre değişir; kurulum öncesi kontrol edilmesi gereken bir noktadır.
Hata Yönetimi
Dış servis çağrısı başarısız olabilir ve bu normal kabul edilmelidir:
| Durum | Yapılacak |
|---|---|
| Zaman aşımı | Önbellekteki veriyi göster |
| Sunucu hatası | Kısa süre sonra tekrar dene |
| Yetki hatası | Tekrar deneme, bildir |
| Hız sınırı aşıldı | Bekle, çağrı sıklığını düşür |
| Beklenmedik yanıt biçimi | Kaydet, güvenli varsayılana dön |
Üçüncü satırdaki ayrım önemlidir: yetki hatasında tekrar denemek anlamsızdır ve hız sınırınızı boşa tüketir — anahtar geçersizse yüz deneme de aynı sonucu verir.
Beşinci satır ise savunmacı programlamanın temelidir. Karşı taraf bir gün yanıt biçimini değiştirebilir; kodunuz bunu varsaymalı ve beklenmedik veriyle karşılaştığında çökmek yerine güvenli bir varsayılana dönmelidir.
API Anahtarı Yönetimi
Dış servisler genellikle bir anahtarla kimlik doğrular. Bu anahtarın korunması gerekir:
- Anahtarı koda gömmeyin. Ayrı bir yapılandırma dosyasında tutun.
- Yapılandırma dosyasını web kökü dışında tutun.
- Sürüm kontrolüne göndermeyin.
- İstemci tarafına asla koymayın. Tarayıcıda görünür.
- Düzenli olarak yenileyin.
Dördüncü madde en sık yapılan ve en pahalı hatadır: JavaScript içine yazılan bir API anahtarı, sayfa kaynağını görüntüleyen herkes tarafından okunabilir.
Anahtar gerektiren çağrılar sunucu tarafında yapılmalı, tarayıcı yalnızca kendi sunucunuza istek göndermelidir. Bu ek adım gibi görünse de tek doğru yaklaşımdır.
Sonuç
Dış API kullanımında tek zorunlu koruma zaman aşımı tanımlamaktır: zaman aşımı ayarlanmamış bir istek, karşı taraf yanıt vermezse dakikalarca asılı kalır ve paylaşımlı hostingde hesabınızın eşzamanlı işlem kotasını doldurur. Mümkün olan her yerde çağrıyı ziyaretçi isteğinden ayırın — zamanlanmış bir görev veriyi çeksin, sayfalar veritabanından okusun. Önbellek yalnızca hız değil dayanıklılık da sağlar: servis çöktüğünde elinizde son bilinen veri kalır. Ve API anahtarını asla istemci tarafına koymayın.
Sıkça Sorulan Sorular (SSS)
Dış servis yavaşlayınca sitem de yavaşlıyor, ne yapmalıyım?
Önce zaman aşımı tanımlayın — hem bağlantı hem toplam süre için. Ardından çağrıyı ziyaretçi isteğinden ayırın: zamanlanmış bir görev veriyi düzenli çeksin ve veritabanına yazsın, sayfalarınız yalnızca oradan okusun. Böylece sayfa hızı dış servise bağımlı olmaz.
Uzak dosya açma kapalı, nasıl istek yaparım?
cURL kullanın — zaten daha doğru tercihtir. Zaman aşımı, başlık yönetimi ve hata kontrolü açısından çok daha fazla denetim sunar. Uzak dosya açmanın kapalı olması yaygın ve yerinde bir güvenlik önlemidir.
Veriyi ne kadar süre önbellekte tutmalıyım?
Verinin değişim hızına göre. Döviz kuru saatlik, kargo takibi birkaç dakika, ürün kataloğu günlük olabilir. Ödeme doğrulaması gibi anlık işlemler ise önbelleklenmez. Önbellek süresi dolup yenileme başarısız olursa eski veriyi göstermeye devam etmek, hata sayfasından iyidir.
API anahtarımı nerede saklamalıyım?
Web kökünün dışındaki bir yapılandırma dosyasında, koda gömmeden ve sürüm kontrolüne göndermeden. Kesinlikle JavaScript içine yazmayın — sayfa kaynağını görüntüleyen herkes okuyabilir. Anahtar gerektiren çağrıları sunucu tarafında yapın.
