¿Qué es el API sprawl? Definición, causas y cómo corregirlo
El API sprawl es cuando las APIs se multiplican más rápido de lo que un equipo puede documentarlas, protegerlas y retirarlas. Causas y cómo evitarlo.
¿Qué es el API sprawl?
El API sprawl es el crecimiento descontrolado de APIs dentro de una organización: el número de APIs, versiones y endpoints crece más rápido que la capacidad del equipo para encontrarlas, documentarlas, protegerlas y retirarlas. Señales típicas: nadie puede listar todas las APIs en producción, varios equipos han creado endpoints casi idénticos y seguridad encuentra APIs sin documentar en una auditoría. El problema no son muchas APIs, sino muchas APIs sin gobernar.
Por qué ocurre
El sprawl es un efecto secundario de crecer. Los microservicios, las integraciones de terceros, las herramientas internas, los backends móviles, las APIs de socios y los sistemas antiguos que siguen en marcha amplían la superficie de APIs, y cada equipo publica lo que necesita. Sin un inventario común ni un paso de revisión, nadie ve el panorama completo. Las APIs internas se multiplican más rápido porque se revisan menos; consulta las APIs internas.
Los cuatro tipos de sprawl
Sprawl de documentación
Las APIs existen, pero su documentación falta o está desfasada. Los desarrolladores buscan el endpoint correcto y la especificación OpenAPI ya no coincide con el código. Solución: generar la especificación a partir del código (o al revés) y validarla en la CI.
APIs duplicadas o solapadas
Tres equipos crean tres endpoints de "crear usuario" porque ninguno conocía a los demás, cada uno con una validación ligeramente distinta. Solución: un catálogo con búsqueda y la norma de consultarlo antes de construir algo nuevo.
APIs en la sombra
APIs que se saltan el gateway, la revisión de seguridad o la monitorización: a veces un endpoint de pruebas que llegó a producción, a veces un atajo deliberado. Son la principal preocupación de seguridad porque nadie vigila su autenticación, sus límites de uso ni sus datos. Solución: descubrimiento de APIs a partir del tráfico real y los logs del gateway, comparado con el catálogo.
APIs zombi
APIs que ya nadie llama pero que siguen funcionando, necesitan parches y exponen datos. Solución: datos de uso por endpoint y un proceso ordenado de retirada; consulta la deprecación de APIs.
Por qué el API sprawl sale caro
- Exposición de seguridad: las APIs sin gobernar tienen más probabilidades de carecer de autenticación, límites de uso o validación de entradas. Consulta la seguridad de APIs.
- Trabajo duplicado: un fallo corregido en una copia sigue abierto en las demás.
- Incorporación más lenta: quien llega aprende qué existe preguntando a personas, no mirando un catálogo.
- Riesgo de cumplimiento: las auditorías preguntan adónde fluyen los datos personales, y no se puede responder por APIs que no se conocen.
- Coste de ejecución: cada servicio en marcha consume cómputo y presupuesto de observabilidad, incluidos los que nadie usa.
Cómo controlar el sprawl
- Un solo catálogo. Un registro único de todas las APIs con responsable, especificación y estado. Constrúyelo a partir del código o del tráfico del gateway, porque las listas mantenidas a mano se quedan obsoletas.
- Pasar por un gateway. Una entrada central deja constancia de cada API y cada consumidor.
- Escribir primero el contrato. Revisar la especificación antes de programar, como en el enfoque API-first.
- Medir el uso por endpoint. Cero tráfico durante un periodo fijado activa una revisión de deprecación.
- Fijar reglas de entrada. Una API nueva necesita entrada en el catálogo, especificación, autenticación y un responsable con nombre antes de recibir tráfico.
API sprawl y monitorización
Un catálogo dice lo que debería existir; la monitorización de APIs dice si funciona. La monitorización de APIs de LoadFocus puede importar una especificación OpenAPI 3.x o Swagger 2.0 y crea un monitor por operación, de modo que una API catalogada recibe comprobaciones de disponibilidad, código de estado y tiempo de respuesta, con alertas a correo, Slack, Microsoft Teams, Discord, PagerDuty, Opsgenie o un webhook genérico. Eso cubre las APIs que conoces; no encuentra las desconocidas, tarea del descubrimiento y de los logs del gateway. Para elegir herramientas, mira las mejores herramientas de monitorización de APIs y cómo ayuda la monitorización de APIs a tu negocio (ambos en inglés).
Errores comunes
- Prohibir APIs nuevas. Los equipos se saltan la prohibición. Haz que el camino gobernado sea el fácil.
- Un catálogo que nadie actualiza. Un catálogo desfasado es peor que ninguno porque la gente confía en él.
- Contar en lugar de gobernar. Mide el porcentaje del tráfico de producción que pasa por APIs catalogadas, no el total.
- Olvidar las APIs que no son REST. GraphQL, gRPC, webhooks y APIs de eventos forman parte de la superficie.
- Ignorar las APIs de terceros. Las APIs externas de las que dependes también van en el catálogo.
- Dejar versiones antiguas en marcha. Sin fecha de retirada, v1, v2 y v3 siguen vivas.
Preguntas frecuentes: API sprawl
¿Cuántas APIs son demasiadas?
El problema no es la cifra, sino la capacidad de encontrarlas y gobernarlas. Una medida útil es el porcentaje del tráfico de producción que pasa por APIs catalogadas y con responsable.
¿El API sprawl es solo un problema de microservicios?
No. Los monolitos también lo sufren, con módulos internos, endpoints sin documentar y scripts que dependen de ellos. Los microservicios lo agravan porque cada servicio es otra superficie de API.
¿En qué se diferencia el API sprawl de la deuda técnica?
Es un tipo concreto de deuda técnica, en el que la superficie de APIs crece más rápido que la capacidad de gobernarla. La deuda técnica incluye también código, frameworks y arquitectura obsoletos.
¿Cómo se encuentran las APIs en la sombra?
Comparando lo que dice el catálogo con lo que realmente recibe tráfico, con logs del gateway, logs del balanceador o análisis pasivo del tráfico, y pidiendo a los responsables que reclamen o retiren cada endpoint desconocido.
¿Qué relación tiene el versionado de APIs con el sprawl?
Cada versión activa es otra API que proteger y mantener. Publica una ventana de deprecación para cada versión y hazla cumplir.
Términos relacionados
- Qué es un bearer token: definición, JWT y seguridad
- ¿Qué es el comando curl? Ejemplos, flags y peticiones HTTP
- ¿Qué es la API History?
- ¿Qué es la idempotencia? Métodos HTTP, idempotency keys, ejemplos
- ¿Qué es JSON? Guía para principiantes con sintaxis y ejemplos
- ¿Qué es JSON-RPC? Protocolo, ejemplos y comparación con REST
- ¿Qué es multipart/form-data Content-Type? Subida de archivos, ejemplos
- ¿Qué es Swagger? Swagger y OpenAPI explicados
Herramientas LoadFocus relacionadas
Lleva este concepto a la práctica con LoadFocus, la misma plataforma que potencia todo lo que acabas de leer.