429 Terlalu Banyak Permintaan: apa artinya dan cara menanganinya

API kembali 429 Too Many Requests saat aplikasi Anda mengirim lebih banyak permintaan daripada yang diizinkan API dalam jangka waktu tertentu. Permintaan itu sendiri baik-baik saja. Anda mengirimnya terlalu sering, sehingga API menolaknya. Jika Anda menunggu dan mengirimkannya lagi, biasanya berhasil. Respons sering menyertakan Retry-After header yang memberi tahu Anda berapa lama menunggu. Untuk informasi selengkapnya, lihat RFC 6585, bagian 4.

Setiap API menerapkan batas permintaan secara berbeda. Kode status, header, dan isi kesalahan semuanya bervariasi, sehingga kode yang menangani satu API dengan benar dapat salah menangani yang berikutnya.

API Status Cara mengetahui berapa lama harus menunggu Hati-hati
GitHub 403 atau 429 retry-after jika ada, jika tidak x-ratelimit-reset (UTC epoch detik) ketika x-ratelimit-remaining adalah 0, jika tidak, setidaknya 1 menit 403 Bisa berupa batas laju permintaan atau izin yang hilang. Baca header untuk membedakannya.
OpenAI 429 retry-after Beberapa error 429, seperti credit_balance_exhausted, berarti bahwa mencoba kembali tidak akan membantu. Periksa error.code.
Anthropic 429 retry-after Batas pengeluaran 429 tidak memiliki retry-after dan terus gagal hingga akses kembali. API yang kelebihan beban mengembalikan 529, bukan 429.
Microsoft Graph 429 Retry-After (detik) Batas berbeda per layanan, misalnya SharePoint dan Outlook.

Cara menangani 429

  1. Putuskan apakah akan mencoba kembali atau tidak. Jika kesalahan mengatakan bahwa kuota, kredit, atau batas pengeluaran Anda habis, percobaan kembali tidak akan membantu. Beri tahu pengguna, dan beri tahu diri Anda sendiri.
  2. Tunggu selama yang diminta API. Jika respons memiliki Retry-After, tunggu selama itu. Nilainya bisa berupa sejumlah detik atau tanggal HTTP. Jika API menggunakan header batas laju sebagai gantinya, seperti GitHubx-ratelimit-reset, tunggu hingga waktu reset.
  3. Jika tidak, mundur. Tanpa petunjuk dari API, coba lagi dengan backoff eksponensial dan jitter acak, dan hentikan setelah beberapa upaya.
  4. Beri tahu pengguna apa yang terjadi. "Sibuk, mencoba lagi dalam 5 detik" lebih baik daripada indikator loading yang tak kunjung selesai.
  5. Perlambat sebelum 429 berikutnya. Jika API mengirim header rate limit, gunakan jumlah yang tersisa untuk mengatur permintaan Anda secara bertahap.
async function fetchWithRetry(url, options, attempts = 3) {
  for (let attempt = 1; ; attempt++) {
    const response = await fetch(url, options);
    if (response.status !== 429 || attempt === attempts) {
      return response;
    }
    const retryAfter = response.headers.get('retry-after');
    const waitMs = retryAfter
      ? (isNaN(retryAfter) ? new Date(retryAfter) - Date.now() : retryAfter * 1000)
      : 2 ** attempt * 1000 + Math.random() * 1000;
    await new Promise(resolve => setTimeout(resolve, Math.max(waitMs, 0)));
  }
}

Banyak SDK akan mencoba lagi permintaan yang mendapat respons 429 untuk Anda. Misalnya, OpenAI Python SDK mencoba kembali 2 kali secara default, dan handler ketahanan standar .NET mencoba kembali 3 kali dan menghormati Retry-After. Ketika SDK kehabisan percobaan ulang, kode Anda menerima error, sehingga masih memerlukan rencana.

Cara menguji bahwa aplikasi Anda menangani 429

Anda jarang melihat 429 saat Anda sedang mengembangkan aplikasi. API cepat, Anda satu-satunya pengguna, dan data pengujian Anda kecil. Jadi cara Anda menguji penanganan 429 memutuskan apakah Anda menemukan bug sebelum pengguna Anda melakukannya.

Approach Apa yang Anda temukan Yang Anda lewatkan
Tunggu proses produksi Kegagalan nyata Semuanya, sampai pengguna menekannya
Mock API dalam pengujian Anda, atau biarkan agen coding Anda menulis mock Apakah cabang percobaan ulang Anda berjalan Kode status, header, dan body error API yang sebenarnya, serta kebijakan coba lagi SDK Anda. Aplikasi Anda juga memerlukan sakelar uji saja untuk mencapai tiruan.
Panggil API nyata sampai permintaan Anda dibatasi Perilaku sesungguhnya Anda tidak dapat memicu 429 sesuai permintaan, dan Anda menghabiskan kuota aktual Anda
Mencegat lalu lintas nyata aplikasi Anda dan mengembalikan 429 sesuai permintaan URL nyata, SDK nyata Anda dan kebijakan percobaan ulang, serta format 429 API itu sendiri Tidak ada perubahan dalam aplikasi Anda, sehingga aplikasi Anda tidak menguji kode Anda dalam isolasi. Gunakan pengujian unit Anda untuk itu saja.

Coba ini di aplikasi Anda

Dev Proxy mencegat permintaan aplikasi Anda ke API yang Anda pilih dan mengembalikan 429, dengan header dan format kesalahan API sendiri, sementara aplikasi Anda terus memanggil URL nyata. Ini juga memberi tahu Anda saat aplikasi Anda mencoba lagi sebelum waktu Retry-After habis.

Unduh prasetel untuk API yang dipanggil aplikasi Anda, dan mulai Dev Proxy dengannya:

devproxy config get github-rate-limiting
devproxy --config-file "~dataFolder/configs/github-rate-limiting/.devproxy/devproxyrc.json"
API Preset
GitHub github-rate-limiting
OpenAI openai-throttling
Anthropic anthropic-throttling
Microsoft Graph (OneDrive dan SharePoint: /drive, /shares, /sites) microsoft-graph-rate-limiting

Kemudian jalankan aplikasi Anda seperti biasa dan tonton apa yang dilakukannya. Untuk menginstal Dev Proxy, lihat Menyiapkan Dev Proxy.

Langkah berikutnya

Uji apakah aplikasi saya menangani pembatasan laju secara efektif

Baca juga

  • Terakhir diperbarui pada