14 errores en la estrategia de API que hay que evitar

Las buenas API son una parte esencial del buen código. Son los límites que los desarrolladores trazamos cuando dividimos proyectos, creamos bibliotecas y compartimos nuestro trabajo. Como dijo Robert Frost hace tiempo, "las buenas vallas hacen buenos vecinos". Si estuviera vivo hoy, estaría escribiendo este poema sobre las API.

Cada vez más, las buenas API son también la base de un buen negocio. No son sólo una puerta de acceso a unos datos y a una inteligencia para la toma de decisiones, sino un producto diseñado para monetizarlos. Las API hacen un seguimiento de sus usuarios y buscan una forma justa de facturarles.

Por desgracia, crear estas API no es tan sencillo como abrir un puerto TCP/IP y esperar a que el dinero lo haga rodar. Si se libera de esta manera, una API recibirá peticiones de todos los dispositivos de Internet y todo el caos, tanto malicioso como inocente, empezará a llamar a la puerta de la empresa. El reto es hacer que una API sea fácil de usar y acogedora para los desarrolladores adecuados y, al mismo tiempo, impenetrable para los equivocados.

 

He aquí 14 problemas comunes de las API que pueden hacer fracasar su estrategia de API.

 

Pasar por alto el precio de la exfiltración

Muchos proveedores de la nube facturan una larga lista de eventos y algunos son fáciles de olvidar. El coste de una máquina por hora es obvio, pero muchos olvidan que la factura puede incluir la "exfiltración de datos". Por desgracia, el principal trabajo de una API es la exfiltración de datos a los usuarios. Asegúrese de tener en cuenta este coste a la hora de fijar el precio de su API, y también al esbozar la arquitectura.

 

Ignorar el "impuesto sobre el formato de datos”

Algunos formatos de datos, como XML, no son tan eficientes como otros, y esto puede afectar al tamaño de los paquetes de datos que devolverá tu API. A una de mis amigas todavía le gusta presumir de cómo redujo las facturas de datos de su empresa en más de un 40% sólo por deshacerse de las etiquetas adicionales y de los residuos en el formato de datos. Mantenga el formato de los datos lo más reducido posible y céntrese en los bits necesarios para que sus facturas de ancho de banda sean manejables.

 

Características exageradas

A veces a los desarrolladores les gusta ser útiles e incluir campanas y silbatos adicionales. La mayoría de las veces, éstas no causan ningún problema, incluso si no se utilizan. Pero a veces dejan agujeros de seguridad que pasan desapercibidos.

El programador que añadió la capacidad de ejecutar código arbitrario a la librería Log4J no planeaba crear uno de los peores fallos de seguridad de la historia de Internet, pero cuando la gente se olvidó del poder de esta característica poco utilizada se convirtió en eso. En casos como este, ayuda no ser demasiado creativo o inteligente. Ceñirse a lo mínimo no siempre es la mejor manera de construir un gran producto, pero puede ser una buena forma de crear una API segura.

 

Olvidar el filtrado previo

La mayoría de las API no hacen mucho trabajo por sí mismas. Toman la entrada y la pasan a otro código. Uno de los mejores servicios que puede ofrecer una API es el prefiltrado para asegurarse de que las entradas se ajustan a las expectativas. Muchos de los peores fallos de seguridad provienen de ataques que abusan de la buena voluntad ingenua de alguna API para desbordar un búfer o generar un ataque de inyección SQL.

 

Escatimar en las pruebas

Muchos desarrolladores tienen unas cuantas URL de prueba básicas. Si el paquete correcto regresa de la API, asumen que todo está funcionando sin problemas. En realidad, los resultados de las pruebas a menudo se almacenan en caché y las simples URL de prueba pueden ejercitar sólo la primera capa. Un buen conjunto de pruebas se asegurará de tocar cada parte de una API, especialmente su conexión con la base de datos y cualquier API o servicio secundario.

 

Desconfiguración de CORS

Los problemas de intercambio de recursos entre orígenes (CORS) pueden aparecer cuando la respuesta de una API se mezcla directamente con algún otro contenido en un navegador. Esto puede ser un reto para algunos usuarios de la API que se apresuran a utilizarla. A veces la respuesta es añadir la etiqueta Access-Control-Allow-Origin a las cabeceras. A veces es mejor construir un proxy completo en la pila.

 

Elegir la autorización incorrecta

Determinar la cantidad correcta de autorización para su API es un poco de arte. Algunos datos no son demasiado sensibles. El único trabajo de la API es hacer un seguimiento de los usuarios para averiguar cualquier factura. Para estos casos más sencillos, una clave aleatoria invariable puede ser suficiente. Otras APIs, sin embargo, protegen información personal que puede ser increíblemente sensible. Para estos casos, protocolos más seguros como OAuth 2.0, OpenID o JWT son mejores opciones. Ya existen buenas bibliotecas para ambos extremos de los protocolos, por lo que actualizar la seguridad no requiere escribir mucho código nuevo.

 

Almacenamiento en caché incorrecto

Las APIs a menudo quieren acelerar las respuestas y ahorrar cálculos almacenando en caché los resultados de las preguntas más comunes. Cuando el almacenamiento en caché funciona bien, todo el mundo recibe una respuesta lo suficientemente fresca para sus propósitos. Pero cuando el almacenamiento en caché es demasiado agresivo, los usuarios acaban recibiendo respuestas obsoletas y sin poder saber cuándo se generaron. El uso de poca o ninguna memoria caché resolverá este problema, pero a costa de más cálculo y complejidad. Encontrar el equilibrio adecuado puede ser un reto.

 

Desarrollar tu propio sistema o utilizar un marco de trabajo

Las APIs son ahora lo suficientemente comunes como para que los programadores hayan construido buenos frameworks como Swagger, OpenAPI, o cualquiera de las versiones comerciales de las compañías de la nube. Sólo tienes que escribir unas pocas líneas para especificar los parámetros y el marco hace la mayor parte del trabajo. Estos marcos tienen buenos filtros para detener el abuso y ofrecen una medición moderna para rastrear el uso. Crear tu propia versión es cada vez más insensato.

 

Ignorar un nivel gratuito

Si su API está destinada a un público general de desarrolladores de una amplia gama de empresas, una capa gratuita puede ser la forma más sencilla de atraer a nuevos usuarios. Si los programadores tienen que pedir al jefe una partida presupuestaria y una autorización, es más difícil que experimenten y muestren a todo el mundo lo que su API puede ofrecer. El peligro, sin embargo, es que el nivel gratuito sea tan generoso que estos desarrolladores sigan utilizando la API sin convertirse en clientes de pago. Encontrar esa cantidad adecuada es un reto y es específico de cada API. Algunas API son fáciles de almacenar en caché porque los datos subyacentes no cambian y eso significa que los usuarios gratuitos pueden estirar el acceso. Sea tacaño con los datos que son fáciles de almacenar en caché durante largos períodos de tiempo. Pero considere la posibilidad de ser más generoso si la salida principal se vuelve obsoleta rápidamente o puede que nunca se almacene en caché.

 

Fijar mal el precio de una API

El mayor reto para un gestor de API que quiera vender el acceso es encontrar la forma correcta de poner precio a los datos. Si la cifra es demasiado baja, no se alcanzan los objetivos de ingresos. Si se fija un precio demasiado alto, la gente se aleja. Todas las técnicas estándar de marketing y fijación de precios son válidas. Algunas empresas reservan niveles premium para captar los ingresos de los grandes usuarios. Otras fijan un precio público elevado y luego ofrecen generosas ofertas privadas. No hay una sola respuesta al problema y la gente en la escuela de negocios escribe doctorados sobre estos desafíos de marketing.

 

No aprovechar las ventajas de la tecnología sin servidor

Herramientas como Cloudflare Workers o Lambda de AWS no son adecuadas para todas las API, pero pueden ser ideales para muchas. Ofrecen un punto de precio simple que es casi directamente proporcional al uso, lo que hace que sea mucho más sencillo diseñar un modelo de negocio que funcione. Si la empresa de la nube cobra X dólares por cada invocación a una función y cada llamada a la API se convierte en una invocación a una función, no es difícil darse cuenta de que tendrás que cobrar al menos X dólares por cada API sólo para poder cubrir los gastos de la infraestructura. Todas las API tienen otros costes y algunos pueden ser sustanciales, pero al menos, los modelos sin servidor facilitan a los contadores de frijoles el precio de algunos de los costes variables para ejecutar una API.            

 

No divertirse con los mensajes de error

¿Quién fue el primero en crear el mensaje 404 personalizado? Hay varias oportunidades en cada API para inyectar algo de humor. Las solicitudes vacías o con formato incorrecto son obvias, pero su API particular podría tener buenos lugares para esconder huevos de Pascua. Los equipos de ingenieros que diseñan Siri y Alexa necesitaban tener una respuesta a "abrir las puertas de la nave". ¿Cuál será la suya?