ZapierやMakeの自動化を新しいジオコーディングホストへ移行する
ジオコーディングのステップを含むノーコードの自動化には、独自のコードとは異なる移行方法が必要です。その切り替えの進め方を紹介します。
Google Maps Platformからの移行：何が変わり、何が変わらないのか
Google Maps Platformは、チームが最初に接続するジオコーディングAPIになることがよくあります。主な理由は、その分野で最も有名な名前だからです。その認証モデルは、今ではほとんどの開発者にとっておなじみのものです。Google Cloudプロジェクト内の請求アカウントに紐付いたAPIキーを、すべてのリクエストでクエリパラメータとして送信します。ジオコーディングのレスポンスは、results 配列、status フィールド、formatted_address 文字列、そして緯度と経度を持つネストされた geometry.location オブジェクトを含むJSONオブジェクトとして返されます。
チームが切り替えについて通常心配するのは、まさにその形式に合わせて作られた解析コードです。住所の構成要素、ビューポートの範囲、プレイスIDなど、そのすべてがコードベースのあちこちに散らばった関数で読み取られており、それらの関数を書き直すのは、誰もスケジュールに入れたがらない種類の作業です。互換ホストは、まさにこの問題を避けるために作られています。
My Geocodeは、Google独自のジオコーディングのリクエストとレスポンスの形式をフィールド単位で再現するGoogle Maps互換ホストを運用しています。レスポンスの中で当社のものであるテキストは、著作権表示、利用規約、プライバシーに関する文言だけです。フィールド名やネストを含め、それ以外はすべて、コードがすでに想定しているものと一致します。実際には、移行とはホスト名とキーを変更することであり、パーサーに手を加えることではありません。詳細は/compatibility/google-maps/にあります。
変わらないこと:
- コードがすでに解析しているJSONの構造
- キーを送信するクエリパラメータの方式(クライアントがそれを使っている場合)
- 全体的なリクエストのパターン(住所を入力し、構造化された位置データを出力)
変わること:
- リクエストの送信先ホスト
- Googleではなく当社が発行するキーそのもの
- 請求アカウントの要件(よりシンプルなクレジットまたはサブスクリプションのモデルに置き換わります)
キーは X-API-Key ヘッダー、Authorization: Bearer ヘッダー、HTTPベーシック認証、クエリパラメータのいずれでも送信できるため、すでに独自の方法で認証しているクライアントライブラリも、変更なしで動作し続けることが多いです。この柔軟性は、聞こえる以上に重要です。実際の移行の苦労の多くは、認証情報を渡す特定の1つの方法を前提としたライブラリから生じるからです。
料金モデルはシンプルです。どのアドレスからでもキーなしで1日2,500件のリクエストが無料で、さらに各キーにはネットワーク単位でカウントされる1日2,500件の無料リクエストがあります。それを超えた分は、1リクエストあたり€0.0001のプリペイドクレジットか、月額€50のUnlimitedパッケージです。すべての互換ホストを含め、すべてのエンドポイントの料金は同じです。どの製品を呼び出すかによって交渉が必要な別々の料金プランはありません。
オプションの追加フィールド(地表の標高、IPの脅威シグナル、ネットワーク詳細)は、mg_extras=1 または X-MG-Extras ヘッダーを追加すれば、コードの他の部分が依存している形式を壊すことなく、どの互換ホストでも利用できます。これにより、2度目の移行をせずに、後からより豊富なデータを利用する道が開けます。
連携が逆ジオコーディング、オートコンプリート、郵便番号検索も扱っている場合も、同じようにホストとキーを入れ替えるだけです。ただし、住所の書式の慣習は国によって異なるため、切り替える前に、それらのエンドポイントの正確なリクエストとレスポンスの形式を現在のコードと照らし合わせて確認する価値があります。完全に切り替える前に本番トラフィックの一部を新しいホストでテストすることは、形式が想定どおりに揃っているかを確かめる妥当な方法です。すべての互換ホストのフィールドの完全なリファレンスは/docs/compatibility/をご覧ください。