今月のリリース:ジオコーディング、IP、タイムゾーンなど
APIの最近の取り組みのまとめです:新しい互換ホスト、より高速なタイムゾーンと標高の検索、ダッシュボードの機能、割り当ての見やすさの向上。
バッチの上限：大手プロバイダーがすでに認めている範囲に合わせています
大手の定評あるプロバイダー向けに作られたバッチ連携は、たいていそのプロバイダーがすでに対応していたバッチサイズを前提に作られています。より小さいサイズでテストする理由はめったになかったからです。同じ連携を新しいプロバイダーに向けるとき、最初に出てくる疑問の1つは、すでに送っているバッチサイズが実際に受け付けられるのか、それとも先に小さく分割する必要があるのかということです。
当社はまさにその懸念を念頭に置いてバッチ処理を作りました。任意の上限を決めてすべての連携にそれに合わせた調整を求めるのではなく、当社の互換ホストが代わりを務める大手プロバイダーがすでに認めている範囲に合わせてバッチ対応のサイズを決めました。GeocodioやGoogle Maps Platform向けの形でバッチを送る連携は、送信先が変わったというだけでそのバッチのサイズを変える必要はないはずです。
バッチリクエストの料金は、サイズにかかわらずまったく同じです。呼び出し全体ではなく、バッチ内の各項目が1リクエストとしてカウントされます。100件の住所のバッチは、適用される割り当てが1日の無料の割り当てでも、1リクエストあたり€0.0001のプリペイドクレジットでも、Unlimitedパッケージによるカバーでも、100リクエストとしてカウントされます。特定のバッチサイズで適用される別の料金はなく、コスト管理のためだけに処理を小さな呼び出しに分ける動機もありません。
これはネイティブのエンドポイントにも互換ホストにも同じように当てはまります。/v1/forwardに直接送ったバッチも、大手プロバイダー向けの形で互換ホストに送ったバッチも、同じ基盤のバッチ処理ロジックで処理され、サイズも料金も同じように扱われ、レスポンスに付く割り当てのヘッダーにも同じように反映されます。
既存のバッチ連携を移行するチームにとって、これは、少なくともバッチサイズの面では移行自体が何事もなく済むはずだということを意味します。/docs/compatibility/の移行ガイドでは、プロバイダーごとに確認すべき詳細を説明していますが、バッチサイズの上限は、切り替えの際に追加のエンジニアリング作業が必要になる項目の1つにはならないはずです。
乗り換えを検討しているプロバイダーに対して現在バッチジョブを実行しているなら、同じバッチサイズを対応するMy Geocodeの互換ホストでテストすれば、実際にこれをすばやく確認できます。無料の割り当てで、何かを約束する前に十分なテストができるため、試すのに費用はかかりません。