ZapierやMakeの自動化を新しいジオコーディングホストへ移行する
ジオコーディングのステップを含むノーコードの自動化には、独自のコードとは異なる移行方法が必要です。その切り替えの進め方を紹介します。
HERE Geocoding and Searchからの移行
HERE Geocoding and Searchは、自動車や物流のソフトウェアでよく使われています。これらは、担当者が決まったエンタープライズアカウントとサポート契約が通常の取引形態である業界です。認証は通常APIキーかOAuthトークンで、レスポンスは items 配列として返され、各要素は position オブジェクトと、label、countryCode、houseNumber などのフィールドを持つ構造化された address ブロックを持っています。
この構造は、それに依存している企業の社内でよく文書化されている傾向があります。HEREは、特定の地域での住所解析の品質や、スタックの別の部分でのルーティングとの連携を理由に選ばれることが多いからです。レスポンスの形式を壊す移行は、その下流のコードすべてを一度に壊してしまいます。だからこそここでは、アカウントそのものの切り替えコストよりも互換性のほうが重要なのです。
My GeocodeのHERE互換ホストは、items配列とそのネストされたpositionおよびaddressのフィールドをHEREが返すとおりに再現しており、置き換わるのは著作権表示、利用規約、プライバシーに関するテキストだけです。フィールドのリファレンスは/compatibility/here/をご覧ください。ほとんどの場合、アプリケーションのコードで必要な変更はホスト名とキーだけで、items[0].position や items[0].address.label を読み取るコードには何の変更も必要ありません。
HEREから移行するエンタープライズのチームでは、ジオコーディングが1つではなく複数のサービスに組み込まれていることが多いため、まずすべての呼び出し箇所を洗い出すと役立ちます。バッチジョブ、住所検証フォーム、配送ルーティング、管理ツールなどは、それぞれ独立して同じAPIを呼び出していることがよくあります。トラフィックの少ないものから始めて1つずつサービスを移行していくのは、最も量の多い呼び出しを切り替える前に、実際の条件下で新しいホストを検証する賢明な方法です。
認証については、My Geocodeが発行したキーを X-API-Key ヘッダー、Authorization: Bearer ヘッダー、HTTPベーシック認証、クエリパラメータのいずれでも送信できます。既存のHEREクライアントライブラリがすでに特定の方法で認証しているなら、通常は新しいキーを使って新しいホストに向けるだけで十分です。ライブラリそのものを変更する必要はありません。
料金面では、エンタープライズ契約にありがちな交渉の手間がなくなります。段階的なアカウント構造はありません。キーなしで1日2,500件のリクエストが無料、各キーにはネットワーク単位でカウントされる1日2,500件の無料リクエストがさらに追加され、それを超えた分は1リクエストあたり€0.0001のプリペイドクレジットか、月額€50のUnlimitedキーです。この互換ホストを含め、すべてのエンドポイントの料金は同じなので、ジオコーディングの量と検索やオートサジェストの量について別々に交渉する必要はありません。
HEREの利用の一部が単純なジオコーディングではなくオートサジェストである場合は、それを独立した移行ステップとして扱う価値があります。オートコンプリート型のエンドポイントには独自のレスポンス形式と、部分的な入力に依存するリクエストのパターンがあるため、ジオコーディングの切り替えにまとめてしまうのではなく、別途テストする必要があります。互換ホストを含むすべてのリクエストの割り当て使用状況は、X-Quota-Used や X-Credits-Remaining などのレスポンスヘッダーで確認でき、/docs/rate-limits/に記載されています。