有効期限のないAPIキーの問題点
何年も前に発行され、一度もローテーションされず、今も有効なキーは、便利なものではありません。何年も誰も実際に確認していない負債です。
互換ホストが新しいSDKより重要な理由
どのAPI企業も、自社のSDKをインストールしてほしいと考えています。SDKは離れにくいものです。コードベースがクライアントライブラリをインポートし、そのメソッドを呼び出し、そのオブジェクト構造に依存するようになると、プロバイダーの乗り換えはURLを変えるだけでは済まず、プロバイダーと通信するコードを書き直すことを意味します。その離れにくさこそが、誰かが口に出して言うかどうかにかかわらず、無料で便利なSDKの背後にある本当のビジネスモデルであることが少なくありません。
私たちは別のアプローチを取りました。My Geocodeには17個の互換ホストがあり、それぞれが他のプロバイダー自身のリクエストとレスポンスの形式を再現しています。あなたのコードがすでに有名なジオコーディングAPIのエンドポイントを呼び出し、そのJSONを解析する方法を知っているなら、そのままのコードを私たちの互換ホストに向ければ動き続けます。インストールするSDKも、書き直すレスポンス解析も、覚えるべき独自のオブジェクトモデルもありません。
本番システムをあるAPIから実際に移行しようとしたことがなければ、これは些細なことに聞こえます。エンドポイントのURLは簡単な部分です。難しいのは、コードベースの中で特定のフィールド名を参照し、特定のエラー形式を処理し、特定のページネーション方式を前提としているすべての箇所です。そうした前提は何年もかけてコードベース全体に散らばり、誰も確認を思い出さない場所に潜んでいます。互換ホストなら、形式が変わらないので、それらを探して修正する必要がなくなります。
これに対してSDKは、初めてAPIに接続するという一度しか直面しない問題を解決する代わりに、製品が存続する限り直面し続ける問題、つまりそのSDKの設計判断に縛られるという問題を生みます。SDKが破壊的変更を出せば、それを受け入れるしかありません。頼りにしている言語バインディングのメンテナンスが止まれば、それも受け入れるしかありません。単純なHTTPの互換ホストには、そうした影響範囲がまったくありません。すでに読み方を知っているレスポンス形式を返すURLにすぎないのです。
私たちはSDK全般に反対しているわけではありません。HTTPの定型コードを書く手間を省く薄いラッパーは、後でそこから離れることがプロバイダーの乗り換えと同じ規模のプロジェクトにならない限り、罠ではなく便利なものです。罠になるのは、SDKの形式があなたのコードが理解できる唯一の形式になり、離れるには設定変更ではなく書き直しが必要になる場合です。
17個の互換ホストを構築するのは、SDKを1つ作るよりも私たちにとって手間のかかる作業でした。既存の連携が違いに気づかないよう、各ホストは他のプロバイダーのレスポンス形式にフィールド単位で忠実に合わせなければなりません。私たちがその作業を行ったのは、乗り換えのコストをあなたの側から私たちの側へ移せるからです。私たちのデータ、稼働率、料金があなたに合うかどうかを、それを確かめるためだけに連携コストを先に支払うことなくテストできます。各ホストが元のAPIとどう対応しているかは、互換ホストの一覧またはドキュメントをご覧ください。
新しいSDKは、プロジェクトが存続する限り企業のエンジニアリング上の選択を信頼するよう開発者に求めます。互換ホストが求めるのはずっと少なく、ベースURLと、場合によってはAPIキーを変えて、どうなるかを見るだけです。そのほうが公平な取引であり、それが私たちが何よりも先に互換ホストを構築した理由です。