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.
El coste silencioso de la dependencia del proveedor
Nadie se registra en una API con la idea de quedar atado a ella. La dependencia no llega como una cláusula de contrato que puedas negociar. Se acumula, una comodidad tras otra, hasta que el coste de cambiar ha crecido en silencio por encima del coste del problema que te hizo plantearte el cambio en primer lugar.
Empieza poco a poco. Instalas el SDK del proveedor porque te ahorra unas horas de escribir llamadas HTTP a mano. Guardas la estructura del objeto de respuesta directamente en tu base de datos en lugar de mapearla a tu propio esquema, porque ese mapeo parecía trabajo innecesario en su momento. Construyes el manejo de errores en torno a los códigos de estado específicos del proveedor en lugar de un patrón general. Cada una de estas decisiones tiene sentido por sí sola, en el momento, bajo la presión normal de las entregas. Ninguna se toma pensando en la dependencia. Todas la aumentan.
Años después, el proveedor sube los precios, sufre una caída en un periodo de mucha actividad o simplemente deja de ser la mejor opción para una función que ahora necesitas. Cambiar debería ser cuestión de elegir un nuevo proveedor y actualizar un valor de configuración. En cambio, es un proyecto: reescribir la lógica de análisis dispersa por el código, rehacer el manejo de errores, readaptar cualquier herramienta interna que haya crecido en torno a la estructura antigua. El coste del cambio nunca apareció en una factura. Se pagó por adelantado, en pequeñas decisiones de integración que nadie señaló como arriesgadas en su momento.
Creamos los hosts compatibles precisamente contra este patrón. Si tu integración ya usa la estructura de solicitud y respuesta de otro proveedor, apuntarla a uno de nuestros 17 hosts compatibles no exige que hayas previsto la portabilidad de antemano. Tienes la opción de marcharte sin haber tenido la previsión de prepararte para ello. Es una diferencia importante frente a la mayoría de los consejos contra la dependencia, que suelen decir "trabaja con una capa de abstracción desde el primer día", un buen consejo que casi nadie sigue realmente bajo la presión de los plazos.
La autenticación es un ejemplo más pequeño del mismo principio. Algunos proveedores te empujan hacia un método de autenticación concreto, lo que ata tu integración a un patrón de cliente determinado. Nosotros aceptamos la clave como encabezado X-API-Key, como encabezado Authorization Bearer, con autenticación HTTP Basic o como parámetro de consulta, en todos los hosts y sin coste extra por ninguno de ellos. Sea cual sea el patrón que tu código ya usa para otras API, el nuestro probablemente encaja, así que no tienes que reescribir tu capa de autenticación solo para probarnos.
La razón honesta por la que la dependencia del proveedor persiste en este sector es que, comercialmente, funciona. Un cliente que se iría solo por el precio a menudo se queda porque marcharse significa reescribir. Creemos que es un mal intercambio sobre el que construir un negocio, porque retiene a los clientes que ya están descontentos en lugar de a los que están realmente satisfechos. Si marcharse sigue siendo barato, los clientes que se quedan lo hacen porque el producto todavía vale la pena, no porque alguien tapiara discretamente la puerta de salida allá por el segundo año.