今月のリリース:ジオコーディング、IP、タイムゾーンなど
APIの最近の取り組みのまとめです:新しい互換ホスト、より高速なタイムゾーンと標高の検索、ダッシュボードの機能、割り当ての見やすさの向上。
検索テーブルの再構築でタイムゾーン検索が高速化
/v1/timezoneへのすべての呼び出しは、座標をタイムゾーンの境界に対応付けるルックアップテーブルに対して実行されます。このテーブルの構造は、応答が返ってくる速さに直接影響します。私たちはこのテーブルを一から作り直し、その結果、エンドポイントはより速く応答するようになりました。
この変更によって、リクエストの形やレスポンスの内容が変わることは一切ありません。/v1/timezoneに座標を送れば、これまでと同じフィールドが返ってきます。タイムゾーン識別子、オフセット情報、そして/docs/timezone-lookup/に記載されているその他のレスポンス構造です。唯一の違いは応答が届くまでの速さです。これは、次々に処理される座標のバッチや、もたつきが許されないリアルタイム機能など、エンドポイントを繰り返し呼び出す用途で特に重要になります。
タイムゾーン検索は、速度の差が積み重なる場所で使われることが多いものです。1回の呼び出しがわずかに速くなっても気づくほどではありませんが、数千件の座標のタイムゾーンを解決するバッチ処理や、ユーザーがピンを動かすたびに現地時刻を表示するライブマップは、どちらも内部の検索が軽くなることで直接恩恵を受けます。バッチリクエストでは各座標がこれまでどおり1件としてカウントされるため、バッチ呼び出しに関する料金や割り当ての挙動もここでは一切変わりません。
この作業は、タイムゾーンエンドポイントに対する私たちのその他の取り組みと並ぶものです。すべてのレスポンスで一貫した割り当てヘッダー、他のすべてのエンドポイントと同じ認証方法、そして直接呼び出しても、位置データを扱う17の互換ホストのいずれかを経由しても同じ料金です。ルックアップテーブルが速くなってもそのどれも変わらず、単に答えがより早く返ってくるだけです。
私たちはこうした内部の再構築を、目玉機能ではなく通常のメンテナンスとして扱っています。それでも取り上げる価値があるのは、このエンドポイントを多用している方にとって効果が現実のものだからです。連携で座標を一括処理している場合や、タイムゾーン検索がレスポンス時間がユーザーに直接影響する処理経路にある場合は、コードを1行も変えずに違いを実感できるはずです。
リクエストパラメーターやレスポンスフィールドを含むこのエンドポイントの完全なドキュメントは、/docs/timezone-lookup/でご覧いただけます。変わったのは応答の速さだけで、それ以外は何も変わっていません。