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.
Una solicitud que se completa correctamente pero sin ningún resultado útil dentro es fácil de gestionar mal, porque no parece un fallo a nivel HTTP; simplemente no trae la respuesta que esperabas.
Una búsqueda de geocodificación directa de algo demasiado vago o totalmente ficticio devuelve un estado 200 con una matriz de resultados vacía, no un código de error.
GET /v1/forward?q=xyzzy nonexistent place&limit=1{
"status": "ok",
"query": "xyzzy nonexistent place",
"results": []
}Una consulta de IP de una dirección en un rango no asignado o privado devuelve found: false en lugar de un error, junto con los campos que aún pueda rellenar.
{
"status": "ok",
"ip": "10.0.0.5",
"version": 4,
"found": false
}Comprueba si la matriz de resultados está vacía, o si hay found: false, como una rama propia en tu código, separada tanto de la ruta de éxito como de la gestión de errores para respuestas 4xx y 5xx. Decide de forma deliberada qué ocurre después: pedir al usuario que precise lo que ha escrito, recurrir a una búsqueda más amplia con un límite mayor o mostrar un mensaje claro de "ubicación no encontrada" en lugar de un espacio en blanco o un valor predeterminado engañoso.
Un lugar que realmente no existe es una causa, pero una cadena de entrada mal formateada, una errata o una consulta que mezcla idiomas o alfabetos de forma inesperada también pueden producir un resultado vacío para una dirección que sí existe. Antes de suponer que la ubicación en sí no existe, piensa si normalizar la entrada o probar una versión con el parámetro countries definido lo resolvería.
Mide con qué frecuencia tu integración pasa por la ruta de resultado vacío, por separado de tu tasa de errores. Un aumento de los resultados vacíos suele apuntar a un problema de calidad de datos anterior, en cómo se recogen o formatean las direcciones, y no a un fallo de la consulta en sí.
Un resultado vacío sigue costando una solicitud, igual que una coincidencia correcta, ya que la consulta se realizó de todos modos. No hay una tarifa reducida para una consulta que vuelve vacía.
Tratar un resultado vacío como un desenlace propio y deliberado, en lugar de un añadido de última hora a la gestión de errores, hace que una integración sea notablemente más sólida. La página de errores cubre las respuestas de error reales, mientras que los resultados vacíos se documentan junto a la forma normal de la respuesta de cada endpoint, como en la documentación de geocodificación directa.