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é los hosts compatibles importan más que un nuevo SDK
Todas las empresas de API quieren que instales su SDK. Un SDK genera dependencia. Una vez que tu código importa una biblioteca cliente, llama a sus métodos y depende de la forma de sus objetos, cambiar de proveedor significa reescribir el código que habla con el proveedor, no solo cambiar una URL. Esa dependencia suele ser el verdadero modelo de negocio detrás de un SDK gratuito y cómodo, lo diga alguien en voz alta o no.
Nosotros adoptamos un enfoque distinto. My Geocode tiene 17 hosts compatibles, cada uno de los cuales reproduce la forma de las solicitudes y respuestas de otro proveedor. Si tu código ya sabe llamar al endpoint de una API de geocodificación conocida y analizar su JSON, puedes apuntar ese mismo código a nuestro host compatible y sigue funcionando. Sin SDK que instalar, sin análisis de respuestas que reescribir, sin un modelo de objetos propietario que aprender.
Parece algo menor hasta que has intentado de verdad migrar un sistema en producción fuera de una API. La URL del endpoint es la parte fácil. La parte difícil es cada lugar de tu código que accede a un nombre de campo concreto, gestiona una forma de error concreta o supone un estilo de paginación concreto. Esas suposiciones se dispersan por el código a lo largo de los años, en lugares que nadie recuerda revisar. Un host compatible elimina la necesidad de encontrarlas y corregirlas, porque la forma no cambia.
Un SDK, en cambio, resuelve un problema que solo tendrás una vez, conectarte a una API por primera vez, a costa de un problema que tendrás durante toda la vida del producto: quedar atado a las decisiones de diseño de ese SDK. Cuando el SDK publica un cambio incompatible, lo absorbes tú. Cuando deja de mantener el binding de un lenguaje del que dependes, también lo absorbes tú. Un host compatible HTTP simple no tiene nada de esa superficie. Es solo una URL que devuelve la forma de respuesta que ya sabes leer.
No estamos en contra de los SDK en general. Un envoltorio ligero que te ahorra escribir código HTTP repetitivo es una comodidad, no una trampa, siempre que dejarlo más adelante no sea el mismo proyecto que cambiar de proveedor. La trampa es cuando las formas del SDK se convierten en las únicas que entiende tu código, de modo que irte significa reescribir en lugar de reconfigurar.
Crear 17 hosts compatibles nos supuso más trabajo del que habría supuesto crear un SDK. Cada host tiene que coincidir estrechamente con la forma de respuesta de otro proveedor, campo por campo, para que las integraciones existentes no noten la diferencia. Hicimos ese trabajo porque traslada el coste del cambio de tu lado al nuestro. Puedes comprobar si nuestros datos, nuestra disponibilidad y nuestros precios te sirven sin pagar antes un coste de integración solo para averiguarlo. Consulta la lista completa de hosts compatibles o la documentación para ver cómo se corresponde cada uno con el original.
Un nuevo SDK pide a un desarrollador que confíe en las decisiones de ingeniería de una empresa durante toda la vida de un proyecto. Un host compatible pide mucho menos: cambiar una URL base, quizá una clave de API, y ver qué pasa. Es un intercambio más justo, y es la razón por la que creamos los hosts compatibles antes que cualquier otra cosa.