頻度制限：トークンバッグまたはスライディングウィンドウ

公開されているAPIにはすべて、リクエスト頻度の制限が必要です。しかし、「1分あたり100リクエスト」という表現には少なくとも4通りの解釈があり、それらはそれぞれ全く異なる動作をもたらします。

固定窓

1分ごとのリクエスト数をカウントし、新しい分が始まると0にリセットする。 最も単純な方法ですが、境界条件の脆弱性があります。ユーザーが59秒目に100件のリクエストを送信し、61秒目にさらに100件のリクエストを送信した場合、つまり2秒間で200件のリクエストが送信されても、依然として有効とみなされてしまいます。

スライド窓

現在時点から過去60秒間のリクエスト数をカウントします。境界の抜けはなくなりますが、リクエストごとにタイムスタンプを記録する必要があるため、メモリを消費します。一般的な折衷案として、現在のウィンドウと前のウィンドウの間で補間を行う方法があります。

トークンウォレット

あるバッグには最大N個のトークンが入っており、時間とともに定期的に補充される。各リクエストには1つのトークンが消費され、トークンがなくなるとリクエストは拒否される。

この機能の優れた点は、制御された一斉送信が可能になることです。ユーザーはしばらく静かに待機して送信数を溜め、その後一気にまとめて送信します。本格的なAPIでは、これは通常望ましい動作です。ユーザーは一定間隔ではなく、まとめて呼び出すことが多いからです。

漏れ

リクエストはキューに入れられ、一定の速度で処理されます。トラフィックを完全に平滑化するため、後続のリクエストがトラフィックの急増に耐えられない場合に適していますが、待ち時間が生じます。

どのように選ぶか

• 開発者向けAPI — トークンウォレット、短期間の急騰はよくあること
• 背後にある脆弱なものを保護 — リークバケツ、流入量を常に一定に保つため
• 悪用やスパム対策 — スライディングウィンドウ、正確な数値が必要だから

どちらを選択しても、残り回数とリセットされるタイミングを示すヘッダーが返されます。制限が明確に示されていないことが、無意味な再試行ループの原因となっています。