有効期限のないAPIキーの問題点
何年も前に発行され、一度もローテーションされず、今も有効なキーは、便利なものではありません。何年も誰も実際に確認していない負債です。
レート制限は発見されるものではなく、文書化されるべきもの
リクエストの失敗が急増することで始まり、開発者が初めてプロバイダーのステータスページを読み、失敗が障害によるものなのか、存在すら知らなかった上限によるものなのかを突き止めようとして終わる、特有のひどい朝があります。そうした朝は完全に避けられるものであり、それがいまだにこの業界全体で起きているのは、インフラではなくドキュメントの失敗です。
レート制限は秘密ではありません。最大リクエストサイズや対応するHTTPメソッドと同じく、システムの運用上の事実であり、同じ場所、つまり誰かが上限に達する前に書き記されているべきものです。当社はレート制限をレート制限のドキュメントで、認証やエラーのページと並べて公開しています。そのため、開発者が計画の前提にすべき数値は、障害のような午後を初めて経験した後ではなく、連携コードの最初の1行を書く前に確認できます。
ただし、ドキュメントだけでは十分ではありません。上限は利用しているプランによって変わることがあり、アカウントの状態が変わった瞬間にドキュメントの情報は古くなるからです。そのため、すべてのレスポンスには、リアルタイムの割り当てヘッダーも付いています。上限、使用量、無料割り当ての残り、ネットワークで共有される割り当ての使用量、プリペイドクレジットの残高、割り当てがリセットされる時刻です。現在の状況を知るために、ドキュメントとダッシュボードを突き合わせる必要はありません。答えは、ひとつひとつの呼び出しのレスポンスそのものと一緒に届きます。
公開された上限を隠すべき競争上の弱点とみなすプロバイダーもあります。数値が見えると、顧客が値下げを交渉したり、競合他社と比較したりするきっかけになるという考えです。当社はその発想は逆だと考えています。誰にも見えない上限だからといって、プロバイダーのインフラをよりよく守れるわけではありません。顧客が実際の数値を初めて知るのが、すでに上限を超えたとき、成長中の製品にとって最悪のタイミングで、しかも自社のユーザーの目の前でということになるだけです。
上限を事前に文書化することで、プロバイダーには設計上の規律も求められます。レート制限を公開するのであれば、それは誰かが責任を持てる実際の数値でなければならず、都合が悪くなるたびにひそかに調整される曖昧な内部のしきい値であってはなりません。数値を書き記し、すべての呼び出しのレスポンスヘッダーに含めるということは、上限が一貫して本当に上限でなければならないということであり、それこそが開発者が上限に求める性質です。
本番環境でリクエストの失敗によってレート制限を発見することは、通過儀礼ではありません。ドキュメントが役割を果たしていないしるしです。当社のドキュメントは、そうしたひどい朝を、自分に起きることではなく、他人に起きた話として読むだけのものにすることを目指しています。