有効期限のないAPIキーの問題点
何年も前に発行され、一度もローテーションされず、今も有効なキーは、便利なものではありません。何年も誰も実際に確認していない負債です。
認証はAPIを使ううえで地味な部分のひとつですが、まさにそうした地味な細部こそ、本来あるべき以上に料金プランの壁の向こうに置かれがちです。一部のプロバイダーは、HTTP Basic認証やBearerトークン方式といった特定の認証方式を上位の有料プラン専用にしており、下位プランでは特定のヘッダー形式ひとつしか使えません。ある認証方式と別の認証方式を検証する技術的なコストの差は、ほぼゼロです。違うのは、それぞれの方式が顧客の既存コードにとってどれだけ扱いやすいかという点であり、それはAPIを使うためにいくら払うべきかとはまったく関係がありません。
当社では、キーをX-API-Keyヘッダー、Authorization Bearerヘッダー、キーをユーザー名とするHTTP Basic認証、またはクエリパラメータのいずれでも受け付けており、すべてのホストで、どの方式にも追加料金はかかりません。既存のコードに合っている方式が何であれ、またチームが他のAPIですでに使っているライブラリや社内の慣習が何であれ、当社がたまたま好む特定の形式に合わせるためだけに何かを作り直さなくても、すでに対応している可能性が非常に高いです。
認証方式をプランごとに制限する理由は、実はコストではありません。それはプランを差別化すること自体が目的になっているからです。提供に追加コストのかからない機能であっても、上位の顧客向けに取っておける機能を探すのは、上位プランの背後に鍵のかかった機能が多いほど、比較表の上で上位プランが価値あるものに見えるからです。認証方式はこの格好の標的です。複数に対応することはプロバイダーにとって本当に手間が少なく、顧客にとっては本当に便利なので、それを制限するのは実際のコスト差に基づく判断ではなく、純粋に収益化のための判断になります。
この種の制限は、実際のデータから得ている価値とは無関係な判断を理由に、開発者を静かに不利に扱うものだと当社は考えます。既存のツールがBearerトークンを標準としているチームが、独自ヘッダーを標準としているチームより多く支払うべきではありません。どちらのチームもまったく同じ検索をし、まったく同じ答えを受け取っているのですから。製品の価値は応答にあります。認証方式は配管にすぎず、既存の壁にたまたまどのパイプが合うかによって配管に値札が付くべきではありません。
ここには、認証に限らず当てはまるより広い原則があります。提供するのにプロバイダー側で追加コストがかからない機能は、できるからという理由だけで人為的なプランの境界にされるべきではありません。リクエスト量のような本当のコスト差に基づいて作られたプラン構成には正当性があります。低コストの便利機能を上位の支払者向けに取っておいて水増ししたプラン構成は、主に、料金ページを実際の製品以上に差別化されているように見せるために存在しています。