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.
Dans la plupart des cas d'usage, notamment la personnalisation, les valeurs par défaut et l'analyse d'audience, la géolocalisation a sa place côté serveur, puisqu'elle ne nécessite aucune coopération du navigateur du visiteur ni aucun script exécuté côté client.
Quel que soit le langage, l'appel est la même simple requête HTTP GET vers /v1/ip, avec la clé envoyée dans un en-tête.
GET /v1/ip?ip=203.0.113.60
X-API-Key: mg_live_examplekey123{
"status": "ok",
"ip": "203.0.113.60",
"version": 4,
"found": true,
"country": "Netherlands",
"country_code": "NL",
"region": "North Holland",
"city": "Amsterdam",
"postcode": "1012",
"lat": 52.3702,
"lon": 4.8952,
"timezone": "Europe/Amsterdam",
"asn": 3344,
"org": "Example ISP"
}Récupérez l'adresse du visiteur dans la requête, généralement $_SERVER['REMOTE_ADDR'], et transmettez-la dans le paramètre ip, puis effectuez la requête HTTP avec le client HTTP déjà utilisé par votre installation PHP, curl ou une bibliothèque qui l'encapsule. Comme ce site est lui-même construit en PHP rendu côté serveur, sans JavaScript côté client, ce modèle s'intègre naturellement au flux de rendu normal d'une page, les données de localisation étant disponibles avant la génération du balisage de la page.
Lisez l'adresse du visiteur dans l'objet de la requête entrante, souvent req.socket.remoteAddress, ou dans un en-tête défini par un reverse proxy, comme X-Forwarded-For, si votre application se trouve derrière l'un d'eux, puis effectuez la même requête GET avec le client HTTP de votre choix avant de générer la réponse.
Si votre application se trouve derrière un répartiteur de charge ou un reverse proxy, l'adresse que votre code voit directement peut être celle du proxy plutôt que celle du visiteur. Vérifiez l'en-tête d'adresse transférée que définit votre proxy et transmettez explicitement cette adresse dans le paramètre ip, plutôt que de vous fier à l'adresse distante brute de la connexion, qui géolocaliserait sinon votre propre infrastructure au lieu du visiteur.
La recherche coûte la même requête unique, qu'elle soit appelée depuis PHP, Node ou tout autre langage backend, puisque le coût dépend de la requête qui atteint l'API, et non de ce qui a émis l'appel. Dans les deux langages, mettez le résultat en cache pour la durée d'une session afin d'éviter de répéter la recherche à chaque page.
La géolocalisation côté serveur fonctionne de la même manière quel que soit le langage backend : un appel HTTP avec l'adresse du visiteur. Toutes les options d'authentification figurent dans la documentation de l'authentification, et la liste des champs dans la documentation de la recherche IPv4.