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é lo construimos como nos gustaría comprarlo
Construimos y operamos una API de geocodificación. Esa es toda la empresa. Cada decisión descrita en el resto de estos artículos (precios por solicitud en lugar de por usuario, un nivel gratuito sin clave en lugar de una prueba con cuenta atrás, hosts compatibles en lugar de un formato propietario, cabeceras de cuota en cada respuesta en lugar de un panel con retraso) se remonta a la misma prueba sencilla que aplicamos una y otra vez mientras lo construíamos: ¿nos molestaría esto si fuéramos el cliente al otro lado?
La mayoría de los malos hábitos sobre los que hemos escrito en esta colección no superan esa prueba desde el primer momento, en cuanto te imaginas siendo tú quien paga por ellos. Nadie quiere descubrir un límite de frecuencia por una solicitud fallida en producción. Nadie quiere un plan «ilimitado» que resulta tener una política de uso razonable asociada. Nadie quiere una migración que lleve un trimestre porque el SDK del proveedor anterior dispersó sus estructuras por todo el código durante años. No son quejas raras. Son cosas que casi todos los desarrolladores han vivido desde el otro lado de una relación con una API, y precisamente por eso creemos que no hace falta investigar a los clientes para identificarlas como problemas que merece la pena evitar.
Los precios fueron el lugar más claro para aplicar esto. 2.500 solicitudes gratuitas al día desde cualquier dirección, sin ninguna clave. Cuando necesitas más, te registras con una dirección de correo electrónico y recargas crédito prepago a 0,0001 € por solicitud o contratas una clave Unlimited por 50 € al mes. Todos los endpoints y todos los hosts compatibles cuestan lo mismo. No llegamos a esto con un ejercicio de optimización de precios pensado para maximizar los ingresos por cliente. Llegamos preguntándonos cómo sería un precio justo y honesto para este producto concreto a ojos de alguien que ya se ha frustrado con niveles opacos, cargos por exceso y llamadas de ventas empresariales, porque todos nosotros habíamos sido ese alguien en algún momento.
La misma prueba se aplica a decisiones más pequeñas que nunca aparecen en una página de precios: aceptar una clave en una cabecera, un token bearer, autenticación Basic o un parámetro de consulta sin coste adicional, porque imponer un patrón concreto es una fricción innecesaria para cualquiera cuyo código ya lo haga de otra forma. Publicar los códigos de error y los límites de frecuencia con claridad, porque adivinar un fallo no documentado es una pérdida de tiempo para todos. Ninguna de estas decisiones es espectacular. Son la acumulación de no hacer lo molesto, una y otra vez, en cada parte del producto.
No decimos que esto haga que todas las partes del producto estén terminadas o sean perfectas. Somos concretos sobre qué endpoints consideramos plenamente operativos y cuáles, como la geocodificación directa, la geocodificación inversa y el autocompletado, describimos con cuidado en lugar de exagerar, porque exagerar es otra versión del mismo fallo: decirle a un cliente lo que quiere oír en lugar de lo que es realmente cierto. Construir el producto que nos gustaría comprar significa construirlo con honestidad, también sobre sus límites actuales, no solo construir las partes de las que es fácil sentirse orgulloso. Ese es el criterio que nos hemos fijado, y es con el que pretendemos que se nos siga midiendo.