El problema de las claves de API que nunca caducan
Una clave emitida hace años, que nunca se ha rotado y que hoy sigue siendo válida, no es una comodidad. Es un riesgo que nadie ha revisado de verdad en años.
Por qué preferimos responder con un error antes que con una suposición equivocada
Una API que siempre devuelve algo, incluso para una solicitud que no puede responder bien, parece más capaz a primera vista que otra que a veces devuelve un error claro. La impresión engaña. Una respuesta que adivina en lugar de admitir la incertidumbre no es más útil. Es más peligrosa, precisamente porque parece exactamente una respuesta segura y correcta y no da a quien llama ninguna señal para comprobar más antes de actuar.
Preferimos devolver un error claro, o una respuesta que indique con claridad una coincidencia de baja confianza o parcial, antes que sustituir en silencio la respuesta por una suposición disfrazada de respuesta normal. Esto importa sobre todo en la geocodificación directa, la geocodificación inversa y el autocompletado, justo los endpoints donde una dirección parcial o ambigua puede tentar a un sistema a devolver la coincidencia plausible más cercana en lugar de reconocer que la entrada no se resolvió con claridad. Una coincidencia plausible más cercana presentada como un resultado normal es la forma más probable de que datos de ubicación erróneos acaben incrustados en un envío, en una comprobación de zona de servicio o en la ficha de un cliente, porque nada en la respuesta indica que hubiera algo incierto.
Esta es también una de las razones por las que somos deliberadamente prudentes a la hora de anunciar una cifra de precisión concreta y verificada para la geocodificación y el autocompletado, en lugar de afirmar que son funciones totalmente terminadas y probadas. Un sistema lo bastante seguro como para publicar una cifra de precisión concreta tiene que estar igual de seguro de lo que ocurre con las entradas que esa cifra no cubre, y la respuesta honesta, para cualquier sistema de geocodificación, incluye una parte de direcciones que deberían volver como no resueltas o ambiguas en lugar de encajarse a la fuerza en una respuesta.
Una respuesta de error tiene un coste en el momento: obliga a la aplicación que llama a gestionar un caso de fallo en lugar de recibir siempre un objeto limpio, y puede parecer una peor experiencia para el desarrollador a primera vista, ya que una suposición que resulta acertada parece idéntica a una respuesta sin errores, y una suposición que resulta equivocada también, hasta que alguien más adelante en la cadena se da cuenta. Ese es exactamente el problema. Una suposición y una respuesta correcta son indistinguibles desde fuera, y precisamente por eso un sistema que no sabe distinguirlas internamente no debería tapar ese hueco eligiendo una y presentándola como segura.
Creemos que esta preferencia, un fallo claro antes que una suposición segura, debería ser una expectativa básica para cualquier API de datos, no solo para la nuestra. Quien llama puede construir un manejo de errores real en torno a un sistema que dice la verdad sobre lo que no sabe. Nadie puede construir un manejo de errores fiable en torno a un sistema que siempre responde, porque no hay forma de distinguir las solicitudes que realmente acertó de aquellas en las que adivinó en silencio y resultó caer del lado equivocado.