ZapierやMakeの自動化を新しいジオコーディングホストへ移行する
ジオコーディングのステップを含むノーコードの自動化には、独自のコードとは異なる移行方法が必要です。その切り替えの進め方を紹介します。
移行中にクライアントライブラリとSDKを更新する
ジオコーディングや位置データの連携の多くは、HTTP APIと直接やり取りしているわけではありません。リクエストをラップし、認証を処理し、アプリケーションの記述言語に応じた型付きオブジェクトとして結果を返す、公式のクライアントライブラリやSDKを経由しています。この追加のレイヤーは日々の作業では便利ですが、移行には現実的な厄介さを加えます。その背後にあるAPIだけでなく、ライブラリ自体も計画に含める必要があるからです。
クライアントライブラリが関わる移行は大きく分けて3つのパターンがあり、始める前にどれに当てはまるかを決めておく価値があります。
ライブラリがカスタムのベースURLに対応している。公式のクライアントライブラリの中には、インターフェースの他の部分を変えずにリクエスト先のベースURLを変更できるほど柔軟に作られているものがあります。その場合、レスポンスの形式がライブラリの解析する想定と一致していれば、既存のライブラリを互換ホストに向けるだけで、アプリケーションのコードをほぼまったく変更せずに動く可能性があります。これが最善のケースであり、最初に確認する価値があります。
ライブラリが1つのホストに強く結び付いている。多くのクライアントライブラリは、接続先のホストをハードコードしていたり、プロバイダーの認証フローに特有の前提を置いていたりして、簡単には向け先を変えられません。この場合、現実的な方法は通常、移行する呼び出しについてはライブラリを完全に迂回し、新しいプロバイダーのAPIに直接リクエストを送ることです。ライブラリの型付きラッパーを、自前の薄いリクエスト関数に置き換えます。
ライブラリがまったく関わっていない。連携がすでに公式ライブラリを挟まずに生のHTTPリクエストを送っているなら、この問題そのものが当てはまりません。移行は、ホスト、キー、そして調整が必要なレスポンスの解析を変更するという、より直接的な作業になります。
My Geocodeの認証はX-API-Keyヘッダー、Authorization: Bearerヘッダー、HTTP Basic認証、またはクエリパラメータに対応しているため、これらの一般的な方式のいずれかですでに認証しているクライアントライブラリは、このプラットフォーム専用の公式ライブラリがなくても、ベースURLの変更と新しいキーだけで互換ホストに対して動く可能性が十分にあります。変更なしで動くとも、まったく動かないとも決めつける前に、ステージング環境で直接テストする価値があります。実際の結果は、そのライブラリがどれだけ柔軟に作られているかに完全に左右されます。
どのパターンに当てはまる場合でも、その判断を移行メモに明記しておく価値があります。移行中に静かに迂回されたのに記録されていないライブラリへの依存は、1年後にコードを保守する人を混乱させがちです。その人は古いライブラリがまだリクエストの経路にあると思って更新するかもしれないからです。リクエストが公式のクライアントライブラリを迂回するようになったことと、その理由を説明する短いコメントがあれば、後々の大きな混乱を防げます。