有効期限のないAPIキーの問題点
何年も前に発行され、一度もローテーションされず、今も有効なキーは、便利なものではありません。何年も誰も実際に確認していない負債です。
ベンダーロックインの見えにくいコスト
ロックインされるつもりでAPIに登録する人はいません。ロックインは、交渉で取り除ける契約条項としてやってくるわけではありません。便利さがひとつずつ積み重なり、やがて乗り換えのコストが、そもそも乗り換えを考えるきっかけになった問題のコストよりも、いつの間にか大きくなっているのです。
始まりは小さなことです。HTTP呼び出しを手で書く時間が数時間節約できるので、プロバイダーのSDKをインストールします。自社のスキーマに変換する作業がその時点では不要に思えたので、レスポンスオブジェクトの形のままデータベースに保存します。一般的なパターンではなく、プロバイダー固有のステータスコードを中心にエラー処理を組みます。こうした選択は、それぞれ単体では、その時点の通常の納期のプレッシャーの中では理にかなっています。どれもロックインを意識して行われたものではありません。しかし、そのすべてがロックインを深めていきます。
何年か後、プロバイダーが値上げをしたり、繁忙期に障害を起こしたり、あるいは今必要になった機能にとって単に最善の選択肢ではなくなったりします。乗り換えは、新しいベンダーを選んで設定値を更新するだけで済むはずです。ところが実際にはプロジェクトになります。コードベースのあちこちに散らばった解析ロジックを書き直し、エラー処理を作り直し、古い形式を前提に育った社内ツールを作り直すことになります。乗り換えのコストが請求書に載ったことは一度もありません。当時は誰もリスクとして指摘しなかった小さな連携上の判断によって、前払いされていたのです。
当社は、まさにこのパターンに対抗するために互換ホストを作りました。連携がすでに他のプロバイダーのリクエストとレスポンスの形式で動いているなら、当社の17の互換ホストのいずれかに向けるだけでよく、あらかじめ移植性を考えて設計しておく必要はありません。離れることを見越して作る先見の明がなくても、離れるという選択肢が手に入ります。これは、ロックインを避けるための多くのアドバイスとは大きく異なります。そうしたアドバイスは「初日から抽象化レイヤーに対して開発せよ」と言いがちで、それは良いアドバイスですが、締め切りのプレッシャーの中で実際に従う人はほとんどいません。
認証は、同じ原則のより小さな例です。一部のプロバイダーは特定の認証方式を使うよう誘導し、連携を特定のクライアントのパターンに縛り付けます。当社では、キーをX-API-Keyヘッダー、Authorization Bearerヘッダー、HTTP Basic認証、またはクエリパラメータのいずれでも受け付けており、すべてのホストで、どの方式にも追加料金はかかりません。既存のコードが他のAPIですでに使っている方式が何であれ、当社のAPIにもおそらく合うので、当社を試すためだけに認証レイヤーを書き直す必要はありません。
この業界でロックインがなくならない正直な理由は、それが商業的にうまくいくからです。価格だけなら離れていくはずの顧客が、離れると書き直しが必要になるという理由でとどまることはよくあります。当社は、それをビジネスの土台にするのは悪い取引だと考えています。本当に満足している顧客ではなく、すでに不満を抱えている顧客をつなぎとめることになるからです。離れるのが安いままであれば、とどまる顧客は、2年目あたりのどこかで出口がこっそりふさがれたからではなく、製品にまだその価値があるからとどまっているのです。