Header Retry-After: berapa lama menunggu sebelum Anda mencoba kembali

Retry-After adalah header respons HTTP yang memberi tahu aplikasi Anda berapa lama menunggu sebelum mengirim permintaan berikutnya. Nilainya dapat berupa sejumlah detik atau tanggal HTTP. Ketika API mengirimkannya, ini adalah jawaban yang paling dapat diandalkan untuk "kapan saya dapat mencoba lagi?" karena berasal dari server yang menolak permintaan Anda. Untuk informasi selengkapnya, lihat RFC 9110, bagian 10.2.3.

Seperti apa tampilan Retry-After

Header memiliki 2 format. Aplikasi Anda perlu menangani keduanya.

Format Example Apa artinya
Seconds Retry-After: 120 Tunggu 120 detik (2 menit) dari saat Anda mendapatkan respons. Nilainya adalah bilangan bulat non-negatif.
Tanggal HTTP Retry-After: Fri, 31 Dec 1999 23:59:59 GMT Jangan kirim permintaan lagi sebelum waktu ini. Tanggal selalu menggunakan GMT.

Server mengirim Retry-After dengan kode status ini:

Status Apa Retry-After artinya Source
429 Too Many Requests Berapa lama menunggu sebelum Anda mengirim permintaan baru. Server mungkin menyertakannya. RFC 6585, bagian 4
503 Service Unavailable Berapa lama layanan diharapkan tidak tersedia. Server mungkin menyertakannya. RFC 9110, bagian 15.6.4
413 Content Too Large Jika kondisi bersifat sementara, server harus menyatakan kapan kondisi tersebut akan berakhir. RFC 9110, bagian 15.5.14
Pengalihan 3xx apa saja Waktu minimum untuk menunggu sebelum Anda mengikuti pengalihan. RFC 9110, bagian 10.2.3

Header bersifat opsional. Beberapa API menggunakan header mereka sendiri sebagai gantinya. Misalnya, GitHub memberi tahu Anda kapan batas Anda diatur ulang melalui x-ratelimit-reset. Untuk informasi selengkapnya, lihat batas laju API GitHub terlampaui.

Cara menangani Retry-After

  1. Baca kedua format. Jika nilainya berupa angka, satuannya adalah detik. Jika tidak, parse sebagai tanggal dan kurangi waktu saat ini. Jika tanggal sudah ada di masa lalu, Anda dapat segera mencoba kembali.
  2. Tunggu setidaknya selama yang tertera pada header. Mencoba lagi lebih awal biasanya akan menampilkan yang lain 429 atau 503. Beberapa API terus menghitung permintaan Anda saat menerapkan throttling pada permintaan Anda, sehingga percobaan ulang awal dapat membuat penantian lebih lama. Misalnya, lihat panduan pembatasan Microsoft Graph.
  3. Gunakan backoff dengan jitter sebagai cadangan ketika header hilang. Gandakan penantian setelah setiap upaya gagal, tambahkan jumlah acak sehingga banyak klien tidak mencoba kembali pada saat yang sama, dan batasi waktu tunggu maksimum.
  4. Batasi percobaan ulang Anda. Setelah beberapa upaya, kembalikan eror ke pemanggil.
  5. Periksa apakah mencoba lagi dapat membantu. Beberapa API mengembalikan 429 saat kredit atau batas pengeluaran Anda habis. Menunggu tidak akan memperbaiki masalah-masalah itu. Misalnya, lihat insufficient_quota dan credit_balance_exhausted OpenAI.
function retryDelayMs(response, attempt) {
  const value = response.headers.get('retry-after');
  if (value) {
    const seconds = Number(value);
    const ms = Number.isNaN(seconds) ? Date.parse(value) - Date.now() : seconds * 1000;
    if (!Number.isNaN(ms)) {
      return Math.max(ms, 0);
    }
  }
  // No usable header: exponential backoff with jitter, capped at 30 seconds
  return Math.random() * Math.min(30_000, 1_000 * 2 ** attempt);
}

Banyak SDK yang menangani Retry-After untuk Anda, tetapi hanya sampai kehabisan percobaan ulang. Kemudian kode Anda mengalami error.

SDK Apa yang dilakukannya secara default
.NET penangan ketahanan standar Mencoba ulang respons 408, 429, dan 5xx hingga 3 kali dengan backoff eksponensial dan jitter. Ini menggunakan Retry-After untuk penundaan karena ShouldRetryAfterHeader default ke true.
SDK untuk Microsoft Graph Gunakan Retry-After saat ada, dan beralih ke backoff eksponensial saat tidak. Permintaan di dalam batch JSON tidak dicoba ulang secara otomatis.
OpenAI Python SDK Mencoba ulang saat terjadi kesalahan koneksi dan respons 408, 409, 429, dan 5xx sebanyak 2 kali dengan backoff eksponensial singkat. Atur max_retries untuk mengubahnya.

Periksa dokumentasi SDK Anda untuk kebijakan yang tepat, dan uji apa yang terjadi setelah upaya percobaan ulang terakhir gagal.

Cara menguji bahwa aplikasi Anda menangani Retry-After

Anda jarang mendapatkan Retry-After saat Anda mengembangkan, dan ketika Anda melakukannya, Anda tidak dapat mengontrol nilainya. Jadi cara Anda menguji ini menentukan apakah Anda menemukan bug sebelum pengguna Anda melakukannya.

Approach Apa yang Anda temukan Yang Anda lewatkan
Tunggu hingga siap produksi Kegagalan aktual Semuanya, sampai pengguna mengkliknya
Mock API dalam pengujian Anda, atau biarkan agen coding Anda menulis mock Apakah kode Anda mengurai header Apakah klien HTTP atau SDK asli Anda menunggu cukup lama, dan apa yang benar-benar dikirim oleh API. Aplikasi Anda juga memerlukan sakelar khusus pengujian untuk mengakses mock.
Panggil API nyata sampai membatasi laju permintaan Anda Perilaku riil Anda tidak dapat memicu respons yang terkena pembatasan laju sesuai permintaan, dan Anda menghabiskan kuota aktual Anda
Mencegat lalu lintas nyata aplikasi Anda dan mengembalikan respons yang diperlambat sesuai permintaan Apakah SDK asli Anda dan kebijakan percobaan ulang Anda menunggu selama yang dinyatakan header Tidak ada yang berubah pada aplikasi Anda, sehingga tidak menguji kode Anda secara terisolasi. Gunakan pengujian unit untuk itu.

Coba ini di aplikasi Anda

Dev Proxy mencegat permintaan aplikasi Anda ke API yang Anda pilih dan mengembalikan 429 respons dengan Retry-After header, sementara aplikasi Anda terus memanggil URL nyata. RetryAfterPlugin mengingat ketika setiap permintaan yang dibatasi dapat dicoba kembali. Jika aplikasi Anda memanggil URL yang sama sebelum waktu tersebut, Dev Proxy melaporkannya dan membatasi permintaan lagi. Plugin hanya melacak 429 respons saja.

Dalam file kesalahan Anda untuk GenericRandomErrorPlugin, atur nilai Retry-After dari respons 429 ke @dynamic, dan Dev Proxy mengisi jumlah detik dan melacaknya untuk Anda.

Untuk mencobanya, unduh preset yang menggunakan kedua plugin, dan mulai Dev Proxy dengannya:

devproxy config get openai-throttling
devproxy --config-file "~dataFolder/configs/openai-throttling/.devproxy/devproxyrc.json"

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