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.
Geolocaliza a un visitante por IP sin un script de terceros
La mayor parte de la geolocalización de IP en la web funciona mediante una etiqueta de JavaScript que llama a un tercero desde el navegador del visitante. Es un script más que cargar, una solicitud más que el navegador tiene que esperar y una cosa más que puede fallar sin avisar si un visitante la bloquea.
Una consulta desde el servidor en su lugar
El endpoint /v1/ip recibe una dirección IP y devuelve directamente los datos de ubicación. Si lo llamas desde tu propio backend, usando la dirección IP que tu servidor web ya ve en la conexión entrante, no se ejecuta ningún script en el navegador del visitante.
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"
}Omitir el parámetro IP
Si llamas a este endpoint sin el parámetro ip, consulta la propia dirección de quien llama, lo que resulta práctico cuando tu backend hace la solicitud en nombre del visitante que está conectado en ese momento. Pasar el parámetro ip de forma explícita es lo que te conviene cuando ya tienes la dirección registrada y la consultas más tarde.
Qué recibes
El país, la región y la ciudad cubren la mayoría de los casos de personalización. El campo timezone significa que a menudo no necesitas una segunda consulta solo para saber la hora local de ese visitante. Los campos asn y org identifican la red a la que pertenece la dirección, lo que es útil para cualquier cosa que vaya más allá de la personalización simple, como detectar proveedores de alojamiento o redes corporativas.
Un caso límite que conviene gestionar
No todas las direcciones se resuelven en una ubicación. El campo found es false para un rango reservado, no asignado o que simplemente no está en el conjunto de datos, y en ese caso los campos de ubicación estarán ausentes o vacíos. Comprueba found antes de leer country o city, en lugar de dar por hecho que una respuesta HTTP correcta siempre significa una ubicación utilizable, ya que una solicitud sobre una dirección privada o reservada seguirá devolviendo un 200 con found en false.
Un error que conviene evitar
Llamar a este endpoint en cada visita a una página, en lugar de una vez por sesión, es la forma más habitual en que un sitio agota su cuota sin ningún beneficio real. La dirección IP de un visitante, y por tanto su ubicación aproximada, no suele cambiar de una página a otra durante la misma visita. Consúltala una vez al iniciar la sesión, guarda el resultado asociado a la sesión y lee esa copia guardada en cada página posterior en lugar de volver a llamar al endpoint.
Coste de las solicitudes y caché
Cada consulta de IP es una solicitud. Como la ubicación de un visitante rara vez cambia dentro de una misma sesión, consúltala una vez y guarda el resultado para la sesión en lugar de llamar al endpoint en cada visita a una página. Así un sitio típico se mantiene holgadamente dentro de las 2.500 solicitudes gratuitas al día incluidas con cada clave o disponibles desde una sola dirección sin ninguna clave.
Una consulta relacionada
El mismo endpoint y la misma estructura de respuesta funcionan con direcciones IPv6 sin ningún cambio en tu solicitud, y el campo version de la respuesta te indica qué familia has recibido. Consulta la documentación de consulta de IPv6 si tu tráfico incluye una proporción significativa de visitantes con IPv6.
Ejecutar esto en el servidor mantiene por completo los scripts de terceros fuera de tu página, lo que importa tanto para la velocidad como para la fiabilidad. Consulta la documentación de consulta de IPv4 para ver la lista completa de campos.