Surveillez l'utilisation de votre clé avant d'atteindre une limite
Surveiller vos en-têtes de quota au fil de l'eau vous indique quand une limite approche, bien avant qu'une requête ne soit effectivement refusée.
Géolocaliser un visiteur par IP sans script tiers
Sur le web, la plupart des géolocalisations IP passent par une balise JavaScript qui appelle un tiers depuis le navigateur du visiteur. C'est un script de plus à charger, une requête de plus que le navigateur doit attendre et un élément de plus qui peut échouer silencieusement si un visiteur le bloque.
Une recherche côté serveur à la place
L'endpoint /v1/ip prend une adresse IP et renvoie directement des données de localisation. Si vous l'appelez depuis votre propre backend, avec l'adresse IP que votre serveur web voit déjà sur la connexion entrante, aucun script ne s'exécute dans le navigateur du visiteur.
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"
}Omettre le paramètre IP
Si vous appelez cet endpoint sans paramètre ip, il recherche l'adresse de l'appelant lui-même, ce qui est pratique lorsque votre backend effectue la requête pour le compte du visiteur qui y est actuellement connecté. Transmettre explicitement le paramètre ip convient lorsque vous avez déjà enregistré l'adresse et que vous la recherchez plus tard.
Ce que vous recevez
Le pays, la région et la ville couvrent la plupart des cas de personnalisation. Grâce au champ timezone, vous n'avez souvent pas besoin d'une seconde recherche simplement pour connaître l'heure locale de ce visiteur. Les champs asn et org identifient le réseau auquel appartient l'adresse, ce qui est utile pour tout ce qui va au-delà de la simple personnalisation, comme repérer des hébergeurs ou des réseaux d'entreprise.
Un cas limite à gérer
Toutes les adresses ne correspondent pas à un lieu. Le champ found vaut false pour une plage réservée, non attribuée ou simplement absente du jeu de données, et les champs de localisation sont alors absents ou vides. Vérifiez found avant de lire country ou city, plutôt que de supposer qu'une réponse HTTP réussie signifie toujours un lieu exploitable, puisqu'une requête portant sur une adresse privée ou réservée renverra quand même un 200 avec found à false.
Une erreur à éviter
Appeler cet endpoint à chaque affichage de page, plutôt qu'une fois par session, est la façon la plus courante pour un site d'épuiser son quota sans réel bénéfice. L'adresse IP d'un visiteur, et donc sa localisation approximative, ne change généralement pas d'une page à l'autre au cours d'une même visite. Recherchez-la une fois au début de la session, stockez le résultat avec la session et lisez cette copie stockée sur chaque page suivante au lieu d'appeler à nouveau l'endpoint.
Coût des requêtes et mise en cache
Chaque recherche d'IP correspond à une requête. Comme la localisation d'un visiteur change rarement au cours d'une session, recherchez-la une fois et stockez le résultat pour la session plutôt que de l'appeler à chaque affichage de page. Un site classique reste ainsi largement dans les 2 500 requêtes gratuites par jour incluses avec chaque clé, ou disponibles depuis une seule adresse sans aucune clé.
Une recherche associée
Le même endpoint et la même structure de réponse fonctionnent pour les adresses IPv6 sans rien changer à votre requête, et le champ version de la réponse vous indique la famille renvoyée. Consultez la documentation de la recherche IPv6 si votre trafic comprend une part significative de visiteurs en IPv6.
Effectuer cette recherche côté serveur tient complètement les scripts tiers à l'écart de votre page, ce qui compte à la fois pour la vitesse et la fiabilité. Consultez la documentation de la recherche IPv4 pour la liste complète des champs.