429 Too Many Requests

Penggunaan

Kode status 429 Too Many Requests menandakan bahwa jumlah permintaan HTTP telah melampaui ambang batas yang diizinkan. Hal ini terjadi, misalnya, ketika server ingin membatasi jumlah pemanggilan API dalam satu jam.

Spesifikasi tidak menentukan bagaimana server menghitung permintaan HTTP atau mengidentifikasi pengguna. Rate limiting dilakukan per sumber daya, atau per pengguna, di seluruh server, atau mencakup beberapa server sekaligus. Identifikasi pengguna dilakukan dengan menggunakan kredensial atau, sebagai alternatif, dengan menggunakan Cookie.

Server secara opsional menyertakan header HTTP Retry-After untuk memberi tahu klien kapan permintaan dapat diterima kembali.

Catatan

Rate limiting membatasi jumlah total permintaan dalam satu jendela waktu (pemutusan tegas), sedangkan throttling memperlambat pemrosesan permintaan dengan mengantrekan atau menunda respons. Durasi menunggu bergantung pada header Retry-After. Tanpa Retry-After, jendela waktu yang umum berkisar antara 60 detik hingga 24 jam tergantung API-nya. Pengguna VPN berbagi alamat IP dengan banyak pengguna lain, sehingga rate limit per IP memengaruhi semua pengguna VPN pada server yang sama.

Dampak SEO

Googlebot memperlakukan 429 sebagai sinyal error server. Ketika sebuah situs mengembalikan respons 429, Google untuk sementara menurunkan laju perayapan di seluruh situs. Begitu respons normal kembali, laju perayapan berangsur pulih. Tidak seperti kode 4xx lainnya, respons 429 memengaruhi crawl budget. Respons 429 yang terus-menerus pada URL terindeks berujung pada penghapusannya dari hasil pencarian. Untuk memperlambat Googlebot, 429 adalah kode status yang tepat. 401 dan 403 tidak menurunkan laju perayapan. Bingbot juga menurunkan laju perayapannya pada respons 429. Bing selain itu mendukung crawl-delay di robots.txt sebagai alternatif throttling berbasis kode status.

Contoh

Klien meminta sebuah sumber daya dan server merespons dengan 429 Too Many Requests.

Permintaan

GET /current-news HTTP/1.1
Host: example.com

Respons

HTTP/1.1 429 Too Many Requests
Retry-After: 1800
Content-Type: text/html
Content-Length: 173

<html>
  <head>
    <title>Request Limit Exceeded</title>
  </head>
  <body>
   <p>The request limit has been reached.
   Try again in 30 minutes.</p>
  </body>
</html>

Cara memperbaiki

Periksa header Retry-After pada respons. Nilainya menyatakan jumlah detik atau sebuah tanggal HTTP yang menunjukkan kapan server menerima permintaan kembali. Hentikan sementara semua permintaan hingga waktu yang ditunjukkan.

Terapkan exponential backoff dengan jitter di antara upaya percobaan ulang. Gandakan waktu tunggu setelah setiap kegagalan (1 dtk, 2 dtk, 4 dtk, 8 dtk) dan tambahkan offset acak untuk mencegah banyak klien mencoba ulang pada saat yang bersamaan dan menciptakan lonjakan trafik baru.

Pantau header rate-limit sebelum menyentuh batas atas. Banyak API menyertakan header X-RateLimit-Limit, X-RateLimit-Remaining, dan X-RateLimit-Reset. Lacak sisa kuota dan perlambat permintaan secara proaktif.

Field rate limit yang terstandardisasi

Di luar header X-RateLimit-* yang menjadi standar de facto, IETF sedang menstandardisasi field respons RateLimit dan RateLimit-Policy untuk memberi sinyal kuota dan waktu reset.

Antrekan permintaan keluar di sisi klien. Antrean permintaan dengan laju pengiriman terkendali mencegah lonjakan melampaui batas. Gabungkan beberapa operasi ke dalam satu pemanggilan API bila endpoint tersebut mendukung operasi massal.

Cache respons untuk data yang diperkirakan tidak berubah antar permintaan. Pemanggilan identik yang berulang adalah sumber paling umum dari konsumsi rate limit yang tidak perlu.

Di sisi server pada nginx, direktif limit_req_zone dan limit_req mengendalikan rate limit per IP atau per endpoint. Setel limit_req_status 429; agar permintaan yang terkena rate limit mengembalikan kode status yang benar alih-alih 503 bawaan. Gunakan parameter burst dan nodelay untuk mengizinkan lonjakan trafik singkat tanpa langsung menolak klien.

Untuk AWS API Gateway, konfigurasikan pengaturan throttle pada level stage atau method. Naikkan kapasitas rate dan burst agar sesuai dengan pola trafik yang diharapkan ketika ambang batas bawaannya terlalu ketat.

Referensi kode

.NET

HttpStatusCode.TooManyRequests

Rust

http::StatusCode::TOO_MANY_REQUESTS

Rails

:too_many_requests

Go

http.StatusTooManyRequests

Symfony

Response::HTTP_TOO_MANY_REQUESTS

Python3.5+

http.HTTPStatus.TOO_MANY_REQUESTS

Apache HttpComponents Core

org.apache.hc.core5.http.HttpStatus.SC_TOO_MANY_REQUESTS

Angular

@angular/common/http/HttpStatusCode.TooManyRequests