Hız Sınırlama

REST API'nin tek bir sınırlayıcısı var ve çoğundan sadedir: IP adresi başına saatte 100 istek. Modelin tamamı bu. Kademe yok, uç bazında bütçe yok, ağır işlemler için ayrı kova yok.

Sayım nasıl işliyor

/api/v1/… adresine gelen her istek, çağıranın IP adresine bir zaman damgası yazar. İstek işlenmeden önce son 60 dakikanın damgaları sayılır; sayı sınıra ulaşmışsa istek reddedilir.

Pencere kayar. Saat başında sıfırlanan bir saat dilimi değildir; yani 14:59'daki altmış istek 15:01'deki altmışla birleşip "bir dakikada 120 istek" üretmez - ilk altmış istek, her biri yapıldıktan tam 60 dakika sonra tek tek düşer.

"IP başına" olmasının insanları şaşırtan üç sonucu var:

Sayaç tek adresin arkasındaki her şey tarafından paylaşılır. Aynı sunucudaki iki n8n akışı ya da tek genel IP'nin arkasındaki bir ofis aynı 100'den harcar. İkinci bir API anahtarı üretmek ikinci bir bütçe getirmez, çünkü anahtarlar hiç sayılmıyor.

Sınırlayıcı kimlik doğrulamadan önce çalışır. Yanlış anahtarlı ya da anahtarsız bir istek de bir hak harcar. Bu kasıtlı: sınır, ucu döven bir betiğe karşı ancak böyle işe yarıyor.

Ve /api/v1/health de sayılır. Otuz saniyede bir yoklayan bir izleme aracı saatte 120 istek harcar ve o adresteki her şeyi kilitler. Beş dakikada bir yoklayın.

CDN ya da ters vekil arkasında, istemci adresi yalnızca bağlantı gerçekten güvenilen bir vekilden geliyorsa yönlendirilmiş başlıklardan alınır - Cloudflare uç adresi ya da kendi ara katmanını önüne koyan bir barındırıcıda yerel adres. Aksi hâlde ham bağlantı adresi kullanılır; yani sahte bir başlıkla başkasının sayacından kaçmak ya da onu zehirlemek mümkün değildir.

429 yanıtı

HTTP/1.1 429 Too Many Requests
Content-Type: application/json; charset=utf-8

{
  "success": false,
  "error": { "code": 429, "message": "Rate limit exceeded" }
}

Yanıtın tamamı bu. Ne bu yanıtta ne de başarılı yanıtlarda Retry-After başlığı ve **X-RateLimit-* başlıkları** vardır - yani istemci ne kadar bütçesi kaldığını okuyamaz, ne zaman dönmesi gerektiği de kendisine söylenmez.

Buradan çıkan pratik kural: 429 gördüğünüzde kendi belirlediğiniz bir takvimle geri çekilin. Örneğin 60 saniye, sonra 5 dakika, sonra vazgeçip uyarı üretin. Sıkı bir döngüde hemen yeniden denemek işe yaramaz, zararlıdır: her deneme de bir istektir ve pencereyi dolu tutar.

Sınırın içinde kalmak

İsteği satıra değil sayfaya harcayın. GET /api/v1/posts?per_page=100 yüz yazı için tek istektir; onları teker teker kimlikle çekmek yüz istek. per_page tavanı 100 olduğundan üç istek üç yüz yazıyı kapsar.

Neredeyse hiç değişmeyeni önbelleğe alın. Kategoriler, etiketler ve ayarlar bir avuç satırdır; günlük bir eşitleme bile doğru sonucu verir. Burada size yardım edecek bir koşullu istek desteği yok: API ETag ve Last-Modified göndermez, yani tekrar çağrı her seferinde tam bir istek harcar. Bundan kaçınmanın tek yolu kendi tarafınızda önbelleklemektir.

Yoklamak yerine olayı dinleyin. Bir şeyin değiştiğini fark etmek için API'yi zamanlayıcıyla çağırıyorsanız, giden webhook bunu bütçenizden hiçbir şey harcamadan size söyler.

Sınırı yükseltme

Değer, config/environment.php içinde tanımlanan API_RATE_LIMIT sabitidir; aynı adda bir ortam değişkeni varsa onu okur. Orada değiştirin, yeni sayı bir sonraki istekte geçerli olur - yeniden başlatılacak bir şey, temizlenecek bir önbellek yok.

Refleksle değil, bilerek yükseltin. Sınırın sebebi şu: paylaşımlı bir sunucuda kontrolden çıkmış bir döngü, sitenin kendisini aç bırakır. "Saatte 100'ü sürekli aşıyoruz" diyorsanız çoğu kurulumda doğru cevap daha büyük bir sayı değil; toplu çalışan ve önbellekleyen bir istemci.