今月のリリース:ジオコーディング、IP、タイムゾーンなど
APIの最近の取り組みのまとめです:新しい互換ホスト、より高速なタイムゾーンと標高の検索、ダッシュボードの機能、割り当ての見やすさの向上。
一括リクエストの数え方：1項目で1単位
100件の住所を含むAPI呼び出しを1回送ると、その呼び出しは1件ではなく100件のリクエストを消費します。私たちは一括リクエストやバッチリクエストに含まれるすべての要素を個別にカウントしています。単純なルールですが、バッチ処理の計画や予算の立て方に影響するため、はっきりと説明しておく価値があります。
バッチ呼び出しが実際に何をしているかを考えれば、この考え方は明快です。100件の住所をジオコーディングする1件のHTTPリクエストは、私たちの側で100単位の作業を行っています。100回の検索、100件の回答、レスポンス内の100行です。これを1件のリクエストとして課金すれば、実際には100件の別々の情報であるものに対して、1セントにも満たない金額を請求することになります。要素ごとにカウントすることで、料金は接続を開いた回数ではなく、実際に行った作業に結び付いたものになります。
これは、無料枠の範囲に近い場合でも、使った分を支払っている場合でも、同じように適用されます。ネットワークの1日の無料割り当てにまだ400件のリクエストが残っているときに1,000件の住所のバッチを送ると、そのうち400件の要素は無料割り当てでまかなわれ、残りの600件はプリペイドクレジットまたはUnlimitedパッケージから差し引かれます。レスポンスの割り当てヘッダーはこれを正確に反映します。X-Quota-Usedは呼び出しの回数ではなく要素の数だけ増え、X-Credits-Remainingにはバッチが無料分を超えて消費した分が反映されます。
また、割り当てを出し抜くために作業を多数の小さな呼び出しに分ける動機もなく、作業をより少ない大きな呼び出しにまとめることによる不利益もありません。要素1件の呼び出し100回と、要素100件の呼び出し1回は、費用もカウントも同じです。コードを書きやすく、インフラで実行しやすいほうの形を選んでください。失敗時の再試行が簡単だという理由で多数の小さな呼び出しを好むチームもあれば、往復の回数が少ないという理由で1回の大きな呼び出しを好むチームもあります。どちらもまったく同じ料金です。
計画を立てるうえで、これにより処理能力の計算が簡単になります。毎日のジョブで50,000件の住所を処理する必要があるなら、それを1回の呼び出しで送っても、10回でも、500回でも、ただ50,000件のリクエストです。無料割り当てを超えた分は1リクエストあたり€0.0001なので、この計算は紙の上で数秒で済みます。
すべてのエンドポイントとすべての互換ホストが、バッチ処理と一括処理について同じ要素単位のカウントに従っています。より安いバッチ専用の料金体系も、より高い料金体系もありません。検索の費用は、単独で届いても、ほかの1,000件と一緒にリストに含まれて届いても同じです。
My Geocodeを使ってバッチ処理を構築する場合は、それらを運ぶHTTP呼び出しの回数ではなく、送る住所、座標、IPの数を数えてリクエスト量を計画してください。割り当てに表示されるのはその数であり、請求書に反映されるのもその数です。