解説
429が出たら連打しない:リクエスト制限とRetry-Afterの見方
ページやAPIで「429 Too Many Requests」が返ってきた。繰り返し押せば直るとは限らず、さらに制限を受けることもあるよ。

ページやAPIで「429 Too Many Requests」が返ってきた。繰り返し押せば直るとは限らず、さらに制限を受けることもあるよ。
このページでは、HTTP 429の意味と、再試行の目安を読む。制限を起こす実験はしない。自分のサービスのログや説明用の応答から確認しよう。
一定の範囲で要求が多い
429は、一定の時間内に要求を送りすぎたときなど、レート制限を示す応答。レート制限とは、要求を受け付ける頻度や量を抑える仕組みだよ。
何回までか、何秒待つか、IP・利用者・APIキーのどれで数えるかはサービスによって違う。429という番号だけで、制限の正確な条件は分からない。
Retry-Afterを読む
応答にRetry-Afterというヘッダーが付く場合がある。再試行までの目安を、秒数またはHTTP形式の日時で表す。
HTTP/1.1 429 Too Many Requests
Retry-After: 60
この例なら60秒後が目安。すべての429に必ず付くわけではないし、待てば必ず成功する約束でもない。継続した制限や契約上の上限が関係する場合は、公式の案内も読む。
人が操作するとき
- 連打やページの再読み込みを止める。
- 表示されている待ち時間や公式の案内を読む。
- 申込・決済などは、先の操作が完了していないか確認する。
- 時間を空けても続く場合は、時刻と操作内容を添えて問い合わせる。
制限を避けるために別のアカウントや接続先へ次々切り替える方法を、対処の基本にはしないよ。秘密のAPIキーを問い合わせの本文へ貼らないことも大切。
プログラムが再試行するとき
待ち時間だけでなく、上限回数や、同時に再試行が集中しない工夫も必要になる。とくに書き込み処理は、同じ操作を繰り返してよい設計かを確認する。
「失敗の応答が見えたから、保存されていないはず」と一律に決めず、サービスの仕様や処理の結果を照合しよう。429の読み方と、再実行の安全性は別の確認だよ。

みんなのコメント 0
感想や、試してみたことを聞かせてね。コメント・返信は承認後に公開されます。
最初のコメントをどうぞ。