X (Twitter) platformunda API rate limitleri nasıl belirleniyor?

30 Eyl 07:35

Twitter API’si aslında bir “window” mantığıyla çalışıyor; belirli bir zaman diliminde (genelde 15 dk) yapılabilecek istek sayısı baştan sabitleniyor. Ücretsiz (Essential) tokenlar için en çok karşılaştığımız limit **450 istek/15 dk** (v2 endpoint’leri için) ya da **300 istek/15 dk** (v1.1 app‑auth) oluyor. Yani dakikada yaklaşık 30 sorgu gönderebilirsin, ama bir anda 100 istek atarsan bir sonraki pencere açılana kadar 429 (Too Many Requests) alırsın. Premium ve Enterprise planlarda bu pencere hâlâ 15 dk’lık, fakat limit değerleri büyük oranda artıyor. Örneğin Academic Research erişiminde **5 000 istek/15 dk**, Business sınıfında ise **25 000 istek/15 dk** gibi rakamlarla karşılaşıyoruz. Ayrıca endpoint‑bazlı farklı limitler var; örneğin “search/tweets” genelde daha sıkı, “users/lookup” daha gevşek. Bu yüzden her endpoint’in dokümantasyonundaki `X‑Rate‑Limit‑Limit` değerine bakmak şart. Rate‑limit aşımını önlemek için en pratik yol, yanıt header’larından üç bilgiyi sürekli kontrol etmek: `X‑Rate‑Limit‑Remaining` (kalan istek), `X‑Rate‑Limit‑Reset` (epoch timestamp olarak pencerenin ne zaman sıfırlandığı) ve `X‑Rate‑Limit‑Limit` (toplam kota). Kalan istek 0’a yaklaştığında bir **exponential backoff** ya da “sleep until reset” stratejisi uygulayabilirsin. Ayrıca istekleri batch’leyip, sık kullanılan verileri cache’lemek ve gerekirse birden fazla uygulama‑token kullanarak “token bucket” modeliyle burstları dağıtmak da işe yarar. Peki ya şu durum: Gerçek zamanlı bir stream (ör. filtered stream) ile çalışırken aniden yüksek bir veri akışı geldiğinde, REST limitlerini zorlamadan nasıl bir **fallback** mekanizması kurarsın? Kanka, birden fazla token arasında dinamik geçiş yapmak ya da stream’i kısa süreli duraklatıp sonra devam ettirmek mantıklı mı?