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é no empezamos creando un SDK para el navegador
Un SDK para navegador es algo fácil de pedir y una idea realmente mala para buena parte de lo que hace de verdad una API de geocodificación o de consulta de IP. Resolver una dirección IP a una ubicación tiene sentido precisamente porque ocurre en el servidor, donde el origen real de la solicitud es visible. Si llevas esa misma consulta a JavaScript del lado del cliente que se ejecuta en el navegador de un visitante, no has hecho la integración más cómoda. Has movido una clave de API autenticada al único lugar de todo el recorrido de la solicitud donde cualquiera puede abrir las herramientas de desarrollo y leerla.
Por eso no dimos prioridad a un SDK para navegador por delante del soporte HTTP simple y de los hosts compatibles. Una clave aceptada como cabecera X-API-Key, token Bearer, autenticación HTTP Basic o parámetro de consulta funciona igual en todos los hosts, llamada desde donde ya vive tu código del lado del servidor: un servicio de backend, una función serverless, un proceso por lotes, cualquier sitio donde la solicitud ya tenga motivos para salir de una infraestructura que controlas y no de una pestaña del navegador que no controlas.
La geolocalización de IP en concreto solo tiene sentido del lado del servidor. Todo el valor de la consulta viene de resolver la dirección IP real que hace la solicitud, y en la mayoría de los casos de uso relevantes (controles de fraude, localización, analítica que controlas tú mismo en lugar de venderla) eso tiene que ocurrir donde esa dirección IP es fiable: tu servidor, que recibe la solicitud directamente, y no un entorno de navegador donde la "IP" que reportaría una llamada del lado del cliente es irrelevante o trivialmente falsificable.
Geocodificar una dirección escrita no es tan claramente algo exclusivo del servidor, y hay un argumento real para querer que el autocompletado de direcciones responda rápido directamente en un formulario, en el navegador, sin pasar antes por tu propio backend. No estamos en contra de que ese patrón exista algún día. Estamos en contra de construirlo como la primera y principal vía de integración, por delante del acceso HTTP simple del lado del servidor que la mayoría de los casos de uso reales (procesos de pago, calculadoras de envío, controles de fraude) necesitan de verdad y que no exige exponer una credencial al público.
El patrón más amplio que rechazamos es tratar "tiene un SDK para navegador" como una casilla que toda API debe marcar, sin importar si el acceso del lado del cliente a ese tipo concreto de datos tiene sentido. Para una consulta en la que el contexto del lado del servidor es precisamente lo importante, un SDK para navegador sobre todo responde a una pregunta de marketing, "¿parece moderno y cómodo?", a costa de una pregunta real de seguridad, "¿dónde acaba viviendo esta credencial?". Preferimos responder primero a la pregunta de seguridad y dejar que la comodidad venga después, no al revés.
Nada de esto descarta una herramienta más ligera y apta para navegador en el futuro, limitada a los casos en los que el uso del lado del cliente tiene sentido de verdad, como un autocompletado de formulario que nunca necesite la credencial real de tu cuenta para funcionar. Lo que no debería ser es lo primero en lo que le pedimos a un cliente que confíe, por delante de la vía HTTP simple que ya cubre de forma segura la mayoría de las integraciones reales.