ZapierやMakeの自動化を新しいジオコーディングホストへ移行する
ジオコーディングのステップを含むノーコードの自動化には、独自のコードとは異なる移行方法が必要です。その切り替えの進め方を紹介します。
ipstack、ip-api.com、ipinfo.io：データ構造の比較
IPジオロケーションプロバイダーの多くは、国、地域、都市、座標、ネットワークの所有者といった、似たカテゴリーの基礎データを利用しています。しかし、それをまとめる形式は目に見えて異なり、プロバイダーを評価したり切り替えたりする際の実際の連携作業の多くは、意外なほどその形式によって左右されます。
ip-api.comはフラットな構造を採用しています。country、regionName、city、lat、lon、isp、query などのフィールドが、ネストなしでレスポンスの最上位に直接並んでいるため、すばやく読むことができ、フラットなデータベースの行や1行のログに簡単に対応付けられます。
ipinfo.ioは、よく組み合わせて使われる2つの値をそれぞれ1つの文字列にまとめています。緯度と経度をカンマ区切りの文字列としてまとめた loc フィールドと、自律システム番号と組織名を1つの文字列にまとめた org フィールドです。後者はAS番号の後に会社名が続くような形になります。これはログの記録やすばやい表示には効率的ですが、どちらの値も、正しい数値として使ったりプログラムで比較したりする前に分割処理が必要です。
ipstackは逆の方向に進み、より多くの構造を持たせています。type、continent_code、latitude、longitude などの最上位フィールドを別々の値として返し、ネットワークとISPの詳細はフラットな文字列ではなく、ネストされた connection オブジェクトにまとめています。これは、その詳細を独立した別個のデータとして扱いたいアプリケーションに適しています。
この3つの形式のどれかが客観的に優れているわけではありません。それぞれ、呼び出し側がデータをどう使うかについての異なる前提を反映しています。フラットな構造は、その場限りの解析コードを書くのが速くなります。コンパクトに文字列を結合した構造は、リクエストごとに1行を保存するログパイプラインで効率的です。ネストされた構造は、より精巧な内部データモデルを構築するアプリケーションのために、関連するフィールドをまとめておくことができます。
My Geocodeは、この3つの形式それぞれにそのまま対応する互換ホストを運用しています。ip-apiのフラットなフィールドは/compatibility/ip-api/、ipinfoのコンパクトな loc と org の文字列は/compatibility/ipinfo/、ipstackのネストされた connection オブジェクトは/compatibility/ipstack/です。つまり、このような比較は、全員のために選ばれた1つの勝者で終わる必要はありません。チームは既存のコードがすでに想定している形式をそのまま使うことができ、評価の段階で同じ基礎検索データに対して複数の形式を試すこともできます。3つのホストはすべて同じプラットフォーム上にあり、認証方法も料金も同じだからです。
ここではIP検索は形式だけでなくエンドツーエンドで完全に動作しているため、この比較は直接試すことができます。小さなスクリプトで3つの互換ホストすべてに同じテスト用IPアドレスを送り、ご自身の解析コードが受け取る実際の出力構造を比較してみてください。どのホストでも、認証には X-API-Key ヘッダー、Authorization: Bearer、HTTPベーシック認証、クエリパラメータのいずれも使えます。また、3つのどのホストでもキーなしで1日あたり2,500件のリクエストが無料なので、1つの形式に決める前に構造を並べて比較するのは低コストで行えます。