Las empresas recurren cada vez más a las API para que sus servicios sean más interoperables y más rentables. Pero tenga cuidado con los siguientes problemas que podrían socavar el valor de su API.

Las buenas Interfaces de Programación de Aplicaciones (API) son una parte esencial de un buen código. Son los límites que trazan los desarrolladores cuando dividimos proyectos, creamos bibliotecas y compartimos nuestro trabajo. Como dijo Robert Frost hace mucho tiempo: “Las buenas cercas 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 entrada a algunos datos e inteligencia para la toma de decisiones, sino un producto diseñado para monetizarlos. Las API rastrean a sus usuarios y descubren una forma justa de facturarles.

Por desgracia, la creación de estas API no es tan simple como abrir un puerto TCP/IP y esperar a que llegue el dinero. Liberada de esta manera, una API tomará solicitudes de todos los dispositivos en Internet, y todo el caos, tanto malicioso como inocente, comenzará a llamar a la puerta de la empresa. El desafío es hacer que una API sea fácil de usar y acogedora para los desarrolladores correctos, mientras que es impenetrable para los incorrectos.

Aquí hay 14 problemas comunes de API que pueden hacer tropezar su estrategia de API:

Pasando por alto el precio de la exfiltración

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

Ignorando el ‘impuesto de formato de datos’

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

Característica hinchada

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

El programador que agregó la capacidad de ejecutar código arbitrario a la biblioteca Log4J no planeó crear uno de los peores errores de seguridad en la historia de Internet, pero cuando la gente se olvidó del poder de esta característica que rara vez se usa, se convirtió en eso. 

En casos como éste, ayuda no ser demasiado creativo o inteligente. Cumplir con lo mínimo no siempre es la mejor manera de crear un gran producto, pero puede ser una buena manera de crear una API segura.

Olvidarse de prefiltrar

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 que las entradas se ajusten a las expectativas. Muchos de los peores errores de seguridad provienen de ataques que abusan de la ingenua buena voluntad de alguna API para desbordar un búfer o generar un ataque de inyección SQL.

Escatimando en las pruebas

Muchos desarrolladores tienen algunas URL de prueba básicas. Si el paquete correcto regresa de la API, asumen que todo funciona sin problemas. En realidad, los resultados de las pruebas a menudo se almacenan en caché y es posible que las URL de prueba simples sólo ejerzan 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.

Configuración incorrecta de CORS

Los problemas de uso compartido de recursos de origen cruzado (CORS) pueden aparecer cuando la respuesta de una API se mezcla directamente con algún otro contenido en un navegador. Esto puede ser un desafío para algunos usuarios de API que se apresuran a usar la API. A veces, la respuesta es agregar la etiqueta Access-Control-Allow-Origin a los encabezados. A veces es mejor construir un proxy completo en la pila.

Elegir la autorización incorrecta

Averiguar la cantidad correcta de autorización para su API es un poco un arte. Algunos datos no son demasiado sensibles. El único trabajo de la API es rastrear a los usuarios para calcular las facturas. Para estos casos más simples, una clave aleatoria inalterable puede ser suficiente. Sin embargo, otras API protegen la información personal que puede ser increíblemente confidencial. Para estos casos, los 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.

No buscar anomalías en el archivo de registro

Cuando el software se está ejecutando y no hay llamadas telefónicas de pánico de los clientes, los programadores tienden a tomar una siesta. Sin embargo, los archivos de registro de las API pueden ayudar a señalar el peligro antes de que ocurra. ¿Algún parámetro en particular está causando más problemas al software? ¿La carga aumenta en días específicos, en momentos específicos o cuando aparece un cliente? 

Pasar sólo unos minutos hojeando los archivos de registro en busca de malos tiempos de respuesta puede resaltar dónde su hardware tiene poca potencia o si su software falla. Solucionar esos problemas ahora evitará un colapso real más adelante cuando una tormenta perfecta entregue varios datagramas desagradables a la vez.

Almacenamiento en caché incorrecto

Las API a menudo quieren acelerar las respuestas y ahorrar cálculos almacenando en caché los resultados de las preguntas comunes. Cuando el almacenamiento en caché funciona bien, todos obtienen una respuesta que aún es lo suficientemente reciente para sus propósitos. Pero cuando el almacenamiento en caché es demasiado agresivo, los usuarios terminan con respuestas obsoletas y sin forma de saber cuándo se generaron. Usar poco o ningún almacenamiento en caché resolverá este problema, pero a costa de más computación y complejidad. Encontrar el equilibrio adecuado puede ser un desafío.

Hacer el tuyo propio versus usar un marco

Las API ahora son lo suficientemente comunes como para que los programadores hayan creado buenos marcos como Swagger, OpenAPI o cualquiera de las versiones comerciales de las empresas de la nube. Sólo escriba algunas líneas para especificar los parámetros y el marco hará 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 su propia versión es cada vez más tonto.

Ignorar un nivel gratuito

Si su API está destinada a una audiencia general de desarrolladores de una amplia gama de empresas, un nivel gratuito puede ser la forma más sencilla para atraer nuevos usuarios. Si los codificadores necesitan pedirle al jefe una línea de presupuesto y una autorización, es más difícil para ellos experimentar y mostrar a todos lo que su API puede proporcionar. Sin embargo, el peligro es que el nivel gratuito sea tan generoso que estos desarrolladores continúen usando la API sin convertirse en clientes de pago. Encontrar la cantidad correcta es un desafío y es específico de la API. Algunas API son fáciles de almacenar en caché porque los datos subyacentes no cambian y eso significa que los usuarios gratuitos pueden ampliar el acceso. Sea tacaño con los datos que son fáciles de almacenar en caché durante largos períodos de tiempo. Pero considere ser más generoso si la salida principal se vuelve obsoleta rápidamente o nunca se almacena en caché.

Fijar el precio de una API

El mayor desafío para un administrador de API que quiere vender el acceso es encontrar la forma correcta de fijar el precio de los datos. Establezca el número demasiado bajo y perderá sus objetivos de ingresos. Póngalo demasiado alto y la gente se alejará. Todas las técnicas estándar de marketing y fijación de precios son un juego limpio. Algunas empresas reservan niveles premium para obtener ingresos de los grandes usuarios. Otros fijan un precio público elevado y luego ofrecen generosos tratos privados. No hay una respuesta para el problema y la gente de la escuela de negocios escribe doctorados sobre estos desafíos de marketing.

No aprovechar 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 funcional. Si la empresa de la nube cobra X número de dólares por cada invocación de función y cada llamada a la API se convierte en una invocación de función, bueno, no es difícil ver que necesitará cobrar al menos X cantidad de dólares por cada API sólo para alcanzar el punto de equilibrio en la infraestructura. Todas las API tienen otros costos y algunos pueden ser sustanciales, pero al menos, los modelos sin servidor facilitan que los contadores de beans fijen el precio de algunos de los costos variables para ejecutar una API.

No divertirse con los mensajes de error

¿Quién creó por primera vez el mensaje 404 personalizado? Hay varias oportunidades en cada API para inyectar algo de humor. Las solicitudes vacías o con un formato incorrecto son obvias, pero su API en particular podría tener buenos lugares para ocultar los huevos de Pascua. 

Peter Wayner, CIO.com