API Rate Limit ve Kota: Müşteriler Arasında Adil Kullanım

Rate limit ile kota aynı ihtiyacı karşılamaz

Hız sınırı kısa sürede gelen istekleri dengelemeyi amaçlar. Kota ise bir müşteri için belirli dönemde kullanılabilecek toplam miktarı tanımlayabilir. Bir müşterinin aylık kotası yüksek olsa da bütün kapasiteyi tek saniyede tüketmesi istenmeyebilir. İki kuralın ayrı açıklanması gerekir.

Ürün paketindeki sınır ile altyapı korumasını da ayırın. Altyapı yoğunluğu nedeniyle geçici sınır uygulamak, müşterinin ticari paketini sessizce değiştirmek olarak sunulmamalıdır. Hata mesajı ve panelde görülen bilgi bu farkı anlatmalıdır.

Sınırın hangi kimliğe uygulandığını belirleyin

IP adresi, API anahtarı, kullanıcı, müşteri kuruluşu ve uç nokta farklı sınır boyutlarıdır. Sadece IP kullanmak ortak ağdaki müşterileri birlikte kısıtlayabilir. Sadece anahtar kullanmak ise aynı müşterinin yeni anahtar açarak sınırı aşmasına yol açabilir. Doğru kombinasyon ürün ve risk modeline göre seçilmelidir.

Ağır bir rapor isteği ile küçük bir durum sorgusu aynı maliyeti taşımayabilir. İstek sayısı yerine işlem maliyetini temsil eden ağırlıklar değerlendirilebilir. Bu ağırlıkların nasıl belirlendiği ve müşteriye nasıl açıklandığı yazılı olmalıdır; rastgele sayılar ürün davranışını belirsizleştirir.

Örnek: tek müşteri toplu rapor başlatıyor

Varsayımsal platformda bir müşteri aynı anda birçok rapor oluşturuyor. Raporlar diğer müşterilerin kısa sorgularını bekletmeye başlıyor. Çözüm, kısa isteklerle uzun işleri farklı kuyruklarda ele almak ve müşteri başına eşzamanlı iş sınırı tanımlamak olabilir.

Tablodaki yaklaşım önerilen bir tasarım çerçevesidir. Gerçek eşikler yük testi ve ürün koşullarıyla belirlenmelidir; bu rehber sabit bir kapasite taahhüdü vermez.

Yeniden denemeyi müşteriye bırakıp unutmayın

HTTP 429, çok fazla istek durumunu ifade etmek için tanımlanmıştır; Retry-After bilgisi uygun koşullarda bekleme yönlendirmesi sağlayabilir. [1] İstemci bu yanıtı aldıktan sonra hiç beklemeden tekrar ederse yoğunluk büyüyebilir. Dokümantasyon örneklerinde sorumlu yeniden deneme davranışı gösterilmelidir.

İşlem yan etkiliyse tekrarın güvenliği ayrıca düşünülmelidir. Sipariş oluşturma veya ödeme başlatma gibi isteği körlemesine tekrarlamak doğru değildir. Kararlı işlem anahtarı, sonuç sorgulama ve belirsiz yanıt yönetimi API sözleşmesinin parçası olmalıdır.

Dağıtık sayaçlarda tutarlılık tercihini açıklayın

Birden fazla sunucu aynı müşteri için sayaç tutuyorsa yerel bellek sayacı toplam kullanımı doğru temsil etmeyebilir. Merkezi veya dağıtık sayaç çözümünün hata halinde ne yapacağı belirlenmelidir. Sayaç servisi erişilemezse istekler kabul mü edilecek, kısıtlanacak mı? Bu karar iş riskine göre verilir.

Dönem değişiminde sayacın sıfırlanması, saat farkları ve geç gelen işler test edilmelidir. Kullanım raporu ile uygulanan sınır farklı kaynaklardan hesaplanıyorsa kullanıcı bir yandan hakkı var görüp diğer yandan engellenebilir. Ortak anlam ve güncellik bilgisi gereklidir.

Kabul testini yalnızca tek istemciyle yapmayın

Aynı müşterinin iki anahtarı, ortak ağdan iki farklı müşteri, kısa ve uzun işler ile dönem sınırı senaryolarını birlikte deneyin. Hata yanıtlarının tutarlılığı API tasarımının önemli bir parçasıdır. [2] Kullanıcı neyi değiştirmesi gerektiğini anlayabilmelidir.

Teslimde sınır sözlüğü, eşiklerin gerekçesi, kullanım görünümü ve operasyon istisnaları bulunsun. Geçici limit artırımı yapılabiliyorsa yetki, süre ve geri dönüş kaydedilsin. Kapasite yönetimi tek bir gizli sayıdan oluşmamalıdır.

Sık sorulan sorular

### IP başına sınır yeterli mi? Her sistem için değil. Ortak ağlar ve birden fazla anahtar kullanan müşteriler farklı sonuçlar doğurabilir. Kimlik ve kaynak boyutlarını birlikte değerlendirin.

Limit hatası alan isteği otomatik tekrar etmeli miyim?

Bekleme ve yeniden deneme kuralını izleyin; işlemin tekrar güvenliğini de kontrol edin. Yan etkili işlemler için kör tekrar yerine işlem kimliği ve sonuç sorgulama gerekebilir.