有効期限のないAPIキーの問題点
何年も前に発行され、一度もローテーションされず、今も有効なキーは、便利なものではありません。何年も誰も実際に確認していない負債です。
退屈で安定したAPIのバージョン管理を支持する理由
プロバイダーがAPIの新しいメジャーバージョンを発表するということは、たいていの場合、既存の連携を持つすべての顧客に、頼んでもいないプロジェクトを発表しているのと同じです。丁寧に告知された破壊的変更であっても、誰かが時間を確保して移行ガイドを読み、リクエストやレスポンスの処理を更新し、テストし、デプロイしなければなりません。そのスケジュールは、顧客自身の製品で起きていることではなく、プロバイダーのロードマップによって決められます。
当社は、APIの安定性を勢いのなさではなく、それ自体を設計目標として扱う価値があるものだと考えています。一度公開されたレスポンス形式は、開発者が最初にそれに合わせて開発したときと同じ意味を持ち続けるべきです。新しいフィールドはオプションの追加として加えられます。標高、IPの脅威情報、ネットワークの詳細が、標準の応答を強制的に再構成するのではなく、その上に重ねるオプトインの追加機能になっているのと同じです。静かに起きてはならないのは、既存フィールドの意味が変わること、ステータスコードが別の用途に転用されること、同じバージョン番号のまま形式が再構成されることです。
この業界で破壊的変更がこれほど頻繁に起きる理由のひとつは、それがプロバイダーにとっては安く顧客にとっては高くつくものであり、双方がその不均衡について直接交渉することがほとんどないからです。よりすっきりした社内モデルをリリースすることは、プロバイダー自身のチームにとって正当なエンジニアリング上の成果です。それが負担に変わるのは、下流のすべての連携に、プロバイダーが決め顧客には決められないスケジュールで対応のための変更を強いた瞬間です。
これは、APIが決して変わってはならないという意味ではありません。変更は可能な限り追加的であるべきで、本当の破壊的変更が避けられない場合でも、それが十分にまれで、顧客が開発時の形式が数か月後や数年後もまだ動くと信頼できるべきだという意味です。身を守るために変更履歴を見張り続けなければならないようなものであってはなりません。安定は停滞と同じではありません。今日の連携作業に、誰にも知らされていない有効期限が付いていないという約束です。
顧客の好意だけでなく、当社がこの立場をとる利己的な理由もあります。当社が運用するすべての互換ホストは、他のプロバイダーの形式に長期にわたって忠実に合わせることに依存しており、それが成り立つのは、一度合わせた形式が安定した対象として頼るに値する場合だけです。自社のAPIを使い捨てのものとして扱い、都合のよいときに再設計する企業は、互換性の保証も本当の保証にはなりません。安定性はあらゆる場所に当てはまる習慣でなければ、実際にはどこにも当てはまりません。
ここで「退屈」は批判ではありません。最初に連携したときとまったく同じように何年も後まで動き続けるAPIのバージョンは、何も改善されなかった証拠ではありません。改善があなたに気づかせる必要のない形で行われた証拠であり、それこそが優れたバージョン管理の規律の目的そのものです。