Controla el uso de tu clave antes de alcanzar un límite
Vigilar las cabeceras de cuota sobre la marcha te indica cuándo te acercas a un límite, mucho antes de que se rechace realmente una solicitud.
Añade geolocalización en el servidor a una app de Node o PHP
En la mayoría de los casos de uso, entre ellos la personalización, los valores por defecto y la analítica, la geolocalización debe hacerse en el servidor, ya que no necesita la colaboración del navegador del visitante ni ningún script ejecutándose en el cliente.
La solicitud en sí
Sea cual sea el lenguaje, la llamada es la misma solicitud HTTP GET simple a /v1/ip, con la clave enviada como cabecera.
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"
}En una app PHP
Obtén la dirección del propio visitante a partir de la solicitud, normalmente $_SERVER['REMOTE_ADDR'], y pásala como parámetro ip; después haz la solicitud HTTP con el cliente HTTP que ya use tu entorno PHP, curl o una biblioteca que lo envuelva. Como este mismo sitio está construido en PHP renderizado en el servidor sin JavaScript en el cliente, este patrón encaja de forma natural en el flujo normal de generación de una página, con los datos de ubicación disponibles antes de generar el marcado de la página.
En una app Node
Lee la dirección del visitante a partir del objeto de la solicitud entrante, normalmente req.socket.remoteAddress o una cabecera definida por un proxy inverso, como X-Forwarded-For, si hay uno delante de tu app, y haz la misma solicitud GET con el cliente HTTP que prefieras antes de generar la respuesta.
Gestionar un proxy delante de tu app
Si tu app está detrás de un balanceador de carga o un proxy inverso, la dirección que ve directamente tu código puede ser la del propio proxy y no la del visitante. Revisa la cabecera de dirección reenviada que defina tu proxy y pasa esa dirección explícitamente como parámetro ip, en lugar de fiarte de la dirección remota sin procesar de la conexión, que de otro modo geolocalizaría tu propia infraestructura en vez de al visitante.
El coste de la solicitud en ambos casos
La consulta cuesta la misma solicitud tanto si se llama desde PHP como desde Node o cualquier otro lenguaje de backend, ya que el coste está ligado a la solicitud que llega a la API, no a lo que hizo la llamada. En cualquiera de los dos lenguajes, guarda el resultado en caché durante la sesión para no repetir la consulta en cada página.
La geolocalización en el servidor funciona igual sea cual sea el lenguaje de backend: una llamada HTTP con la dirección del visitante. Todas las opciones de autenticación están en la documentación de autenticación, y la lista de campos está en la documentación de consulta de IPv4.