上限に達する前にキーの使用状況を監視する
割り当てヘッダーを随時確認しておけば、リクエストが実際に拒否されるよりずっと前に、上限が近づいていることが分かります。
サードパーティのスクリプトを使わずにIPで訪問者の位置を特定する
Web上のIPジオロケーションの多くは、訪問者のブラウザーからサードパーティを呼び出すJavaScriptタグを通じて行われています。それは読み込むスクリプトが1つ増え、ブラウザーが待たなければならないリクエストが1つ増え、訪問者がブロックすると気づかないうちに失敗しうる要素が1つ増えるということです。
代わりにサーバー側で検索する
/v1/ipエンドポイントはIPアドレスを受け取り、位置データを直接返します。Webサーバーが受信した接続ですでに把握しているIPアドレスを使って自社のバックエンドから呼び出せば、訪問者のブラウザーで動くスクリプトは一切ありません。
GET /v1/ip?ip=203.0.113.42{
"status": "ok",
"ip": "203.0.113.42",
"version": 4,
"found": true,
"country": "France",
"country_code": "FR",
"region": "Ile-de-France",
"city": "Paris",
"postcode": "75001",
"lat": 48.8566,
"lon": 2.3522,
"timezone": "Europe/Paris",
"asn": 12345,
"org": "Example Networks"
}IPパラメーターを省略する
ipパラメーターを付けずにこのエンドポイントを呼び出すと、呼び出し元自身のアドレスを検索します。これは、バックエンドが現在接続している訪問者に代わってリクエストを送る場合に便利です。すでに記録してあるアドレスを後から検索する場合は、ipパラメーターを明示的に渡してください。
返される内容
国、地域、市区町村があれば、パーソナライズのほとんどの用途をまかなえます。timezoneフィールドがあるため、その訪問者の現地時刻を知るためだけに2回目の検索をする必要がないことも多いでしょう。asnとorgのフィールドはアドレスが属するネットワークを示し、ホスティング事業者や企業ネットワークの見分けなど、単純なパーソナライズ以外の用途に役立ちます。
対処しておくべきエッジケース
すべてのアドレスが位置に解決されるわけではありません。予約済み、未割り当て、あるいは単にデータセットに含まれていない範囲では、foundフィールドがfalseになり、その場合は位置のフィールドが存在しないか空になります。プライベートアドレスや予約済みアドレスに対するリクエストでも、foundがfalseの状態で200が返されるため、HTTPレスポンスが成功したからといって常に使える位置が得られると決めつけず、countryやcityを読む前にfoundを確認してください。
避けるべき間違い
セッションごとに1回ではなく、ページが表示されるたびにこのエンドポイントを呼び出すことは、サイトが実質的なメリットもなく割り当てを使い切ってしまう最もよくある原因です。訪問者のIPアドレス、つまりおおよその位置は、同じ訪問の中でページを移動しても通常は変わりません。セッション開始時に一度だけ検索して結果をセッションに保存し、以降のページではエンドポイントを再び呼び出すのではなく、その保存したコピーを読み出してください。
リクエストの費用とキャッシュ
IP検索は1回につき1件のリクエストです。訪問者の位置は1回のセッションの中でほとんど変わらないため、ページが表示されるたびに呼び出すのではなく、一度検索してセッションの間その結果を保存してください。そうすれば、一般的なサイトであれば、すべてのキーに含まれる、あるいはキーがなくても1つのアドレスから利用できる1日あたりの無料リクエスト2,500件の範囲に十分収まります。
関連する検索
同じエンドポイントと同じレスポンス構造は、リクエストを一切変えずにIPv6アドレスでも使えます。レスポンスのversionフィールドを見れば、どちらのアドレスファミリーが返ってきたかがわかります。トラフィックにIPv6の訪問者がかなりの割合で含まれる場合は、IPv6検索のドキュメントをご覧ください。
これをサーバー側で実行すれば、サードパーティのスクリプトをページから完全に排除でき、速度と信頼性の両面で効果があります。フィールドの完全な一覧はIPv4検索のドキュメントをご覧ください。