上限に達する前にキーの使用状況を監視する
割り当てヘッダーを随時確認しておけば、リクエストが実際に拒否されるよりずっと前に、上限が近づいていることが分かります。
訪問者のIPアドレスから推測される国を初期値とする国のドロップダウンがあれば、ほとんどの人は長いリストをスクロールせずに済みます。ただし、初期値が間違っている場合に変更できることが前提です。
ページがリクエストされたときにサーバー上で訪問者のIPアドレスを検索し、レスポンスのcountry_codeフィールドを読み取って、ページがブラウザに送信される前にドロップダウンの選択済みオプションとして設定します。
GET /v1/ip?ip=192.0.2.15{
"status": "ok",
"ip": "192.0.2.15",
"version": 4,
"found": true,
"country": "Spain",
"country_code": "ES",
"region": "Madrid",
"city": "Madrid",
"postcode": "28001",
"lat": 40.4168,
"lon": -3.7038,
"timezone": "Europe/Madrid",
"asn": 5678,
"org": "Example Networks"
}これはすべてページのレンダリング前にサーバー側で行われるため、間違った初期値が一瞬表示されてからブラウザで修正される、ということがありません。ページの読み込み後に外部を呼び出すクライアント側の方法では、こうしたことが起こります。生成するHTMLの中で、該当するオプションに直接selected属性を設定し、country_codeを、オプションの値としてすでに使っているISOコードと照合します。
同じ呼び出しは、新規登録フォームと同じようにチェックアウトページでも機能します。チェックアウトページの読み込み時に買い物客のIPを一度検索し、country_codeを配送先の国のリストと照合して、初期値として選択します。配送先の国はページの下のほうに表示される税金や配送オプションに影響するため、ページのレンダリング前にこれを正しく設定しておけば、間違った初期値のまま他のすべてが読み込まれた後に訪問者が修正しなければならず、レイアウトが大きく崩れる、という事態を避けられます。
IPに基づく国は出発点として扱い、確定した答えとして扱わないでください。旅行中の訪問者、会社のVPNを使っている訪問者、あるいは単にネットワークプロバイダーの登録住所と一致しない場所に住んでいる訪問者は、別のオプションを選ぶ必要があります。そのため、フォームのどの部分も初期値が正しいと想定すべきではありません。
完全にレンダリングされたページを、訪問者ごとに変化させずにCDNやリバースプロキシの背後でキャッシュしないでください。最初の訪問者のIPで一度レンダリングされたページがキャッシュからその後の全員に配信されると、実際にどこにいるかに関係なく、後続のすべての訪問者に最初の訪問者の国が表示されてしまいます。ページをキャッシュしている場合は、この部分をキャッシュから除外するか、リクエストごとに実行される小さなサーバーサイドインクルードでレンダリングしてください。
一部のプライベートな範囲や未割り当ての範囲ではfoundがfalseで返ってきます。その場合は、フィールドを未定義の状態のままにせず、空の選択や最も多い国など、中立的な初期値にフォールバックしてください。
IPv6で接続する訪問者にも、同じエンドポイントから同じcountry_codeフィールドが返されます。違いは、/24ではなく/48のネットワークに対して解決される点だけです。どちらのIPバージョンでリクエストされたかによって、ドロップダウンのロジックを変更する必要はまったくありません。バージョン固有の詳細については、IPv6検索のドキュメントをご覧ください。
新しい訪問者のセッションごとに1件のリクエストで、セッションの間はキャッシュされるため、1回の訪問で複数のフォームページにわたって検索が繰り返されることはありません。そのため、よほど混雑しているサイトでない限り、この機能はすべてのキーに含まれる、またはキーなしで1つのアドレスから利用できる1日あたり2,500件の無料リクエストの範囲に十分収まります。
適切な初期値があれば100項目のリストをスクロールせずに済み、推測が外れた場合でも訪問者が完全にコントロールできます。フィールドの詳細はIPv4検索のドキュメントにあります。