今月のリリース:ジオコーディング、IP、タイムゾーンなど
APIの最近の取り組みのまとめです:新しい互換ホスト、より高速なタイムゾーンと標高の検索、ダッシュボードの機能、割り当ての見やすさの向上。
郵便番号検索専用のエンドポイント
位置に関する質問のすべてが、本当にジオコーディングの質問というわけではありません。アプリケーションが実際に必要としているのが、ある地域の郵便番号、またはある郵便番号がカバーする地域だけで、ジオコーディングや逆ジオコーディングが提供する広範な住所の解決は不要な場合もあります。/v1/postcodeは、まさにその限定された質問のために、より汎用的な検索の副産物ではなく、独立した専用のエンドポイントとして存在します。
/v1/forwardや/v1/reverseと分けておくことには、いくつかの実用的な理由があります。まず、リクエストの形式を、より広い住所の構造から流用するのではなく、郵便番号のパラメーターに特化して設計できます。次に、レスポンスを郵便番号だけの連携に本当に必要なものに絞り込めるため、余分な住所フィールドを除外する必要がありません。そして、/docs/postal-code-lookup/で全文を公開しているドキュメントで、郵便番号の挙動を長いジオコーディングガイドの一節としてではなく、それ自体として説明できます。
認証は他のすべてのエンドポイントと同じルールに従います。X-API-Keyヘッダー、Authorization: Bearerヘッダー、キーをユーザー名とするHTTP Basic認証、またはクエリパラメーターのいずれも、同じように受け付けます。料金も同じで、呼び出し元のネットワークまたはキーの同じ1日あたりの無料割り当てを消費し、それを超えるとプリペイドクレジットで同じ1リクエストあたり€0.0001、またはUnlimitedパッケージの対象となります。
バッチリクエストは、プラットフォームの他のすべての場所とまったく同じように動作します。1回の呼び出しで送信した郵便番号や住所はそれぞれ1件のリクエストとしてカウントされ、呼び出し全体で1件になるわけではありません。大規模な顧客リスト全体の郵便番号を検証するチームは、そのリストをバッチで送信でき、My Geocodeの他の一括処理と同じ項目ごとのカウントが適用されます。
専用のエンドポイントがあることで、17の互換ホストにおける郵便番号の互換性もより正確になります。独自の郵便番号検索を提供しているプロバイダーに対して、より広いジオコーディングの形式で近似するのではなく、正確に合わせられるからです。
アプリケーションが郵便番号の情報だけを必要としていて、その1つのフィールドを取り出すためだけにこれまで広範なジオコーディングのリクエストを送っていた場合は、/v1/postcodeに直接切り替える価値があります。完全なドキュメントは/docs/postal-code-lookup/にあり、その他のエンドポイントのリファレンスは/docs/にあります。