¿Qué es el ciclo de vida de la API?

Las API son conjuntos de reglas o protocolos que permiten que las aplicaciones de software se comuniquen entre sí para intercambiar datos, características y funcionalidad. Existe un ciclo de vida del productor de API, centrado en la creación y distribución de API, y un ciclo de vida del consumidor de API, centrado en el uso de API desde el punto de vista del consumidor. Este artículo se centra en el ciclo de vida del productor de API.

No existe un ciclo de vida universal del productor de API. Es posible que vea diferentes variaciones de diferentes fuentes, pero el ciclo de vida generalmente incluye las siguientes etapas: planear, diseñar, desarrollar, probar, desplegar, monitorear y retirar.

Las plataformas de gestión de API se emplean a menudo para organizar los esfuerzos a lo largo del ciclo de vida de una API, y para centralizar la estrategia, la gobernanza, la documentación y los directorios de API en todo un entorno de TI. Muchas plataformas incluyen capacidades y herramientas de analytics avanzadas para el descubrimiento y la monetización de API que ayudan a las organizaciones a aprovechar al máximo sus API.

Tener en cuenta y comprender todo el ciclo de vida de la API ayuda a los equipos de desarrollo a asignar recursos de forma más eficiente, crear plazos realistas para la entrega, mantener informados a todos los stakeholders durante todo el proceso y garantizar que las API cumplan con los requisitos empresariales. Esencialmente, un ciclo de vida bien pensado y ejecutado ayuda a ofrecer API seguras y de alto rendimiento y una experiencia de usuario más sólida.

La gestión integral del ciclo de vida de la API comprende varias etapas clave, que comienzan con la planificación preliminar y terminan, a menudo, pero no siempre, con el retiro o el reemplazo. Como ejemplo, consideremos una empresa de software que decide crear una API para sincronizar los datos de sus clientes con herramientas empresariales, como tickets de soporte, sistemas de contabilidad, plataformas de gestión de proyectos y más.

La creación de una API comienza con responder algunas preguntas fundamentales: ¿por qué es necesaria esta API, para quién es, cómo se utilizará y cómo se medirá el éxito? 

La especificidad sobre el objetivo del proyecto de API puede ayudar a aclarar qué características y funcionalidades debe tener el diseño de la API. En el ejemplo del desarrollo de software, el objetivo de la API es garantizar que los datos de los clientes puedan transferirse sin problemas entre las aplicaciones y plataformas que la empresa utiliza o tiene previsto utilizar. 

En esta fase de planificación, las organizaciones:

• Revisan los posibles beneficios para el negocio de la API
• Describen cómo esta API abordará las necesidades del negocio
• Garantizan que no existan API u otros productos disponibles en los mercados de integración nativa que puedan cumplir con los requisitos (básicamente, para confirmar que es necesario desarrollar esta API)
• Delimitan claramente qué aplicaciones y plataformas dependerán de la API y cómo se integrará la API con los flujos de trabajo existentes.

A continuación, el equipo debería analizar los posibles usuarios y los casos de uso. ¿Esto es meramente para uso interno? ¿Qué equipos utilizarán esta API y para qué? ¿Hay problemas de seguridad que deban abordarse en las fases de diseño y desarrollo? Y lo que es más importante, ¿quién será responsable de cada fase de la producción de la API?

Establecer un cronograma para completar el proyecto ayuda a garantizar que el proyecto se mantenga dentro del presupuesto. Es importante que los plazos sean realistas y flexibles. 

Los equipos responderán a preguntas como: ¿hay fechas específicas, como una fecha de lanzamiento de una nueva funcionalidad, que deban cumplirse? ¿Hay equipos de seguridad o cumplimiento legal u otros stakeholders que deban aprobar antes de que se pueda desplegar esta API? 

¿Dónde se almacenará y pondrá a disposición de los desarrolladores y usuarios la documentación y otra información sobre la API? ¿Dónde se rastrearán y almacenarán los cambios de código?

Responder a este tipo de preguntas desde el principio ayuda a establecer un plan claro para el resto del ciclo de vida.

Mientras que la etapa de planificación describe el resultado deseado, la etapa de diseño define cómo el equipo planea llegar allí. A lo largo del proceso de diseño, el equipo de diseño de API decide cómo se debe construir la API para satisfacer los requisitos detallados en la fase de planificación. 

El equipo debe tomar decisiones de diseño con respecto al protocolo y el estilo arquitectónico que utilizará la API. Esta decisión puede basarse en la arquitectura de API existente en la organización o en los casos de uso previstos para esta nueva API.

Por ejemplo, los marcos y arquitecturas de API comunes incluyen REST, GraphQL y gRPC; cada uno tiene sus propias fortalezas y debilidades. 

• REST: simple, intuitivo y omnipresente, pero no ideal para consultas complejas y no ofrece una mecanografía sólida.
  
  
• GraphQL: eficiente, con mecanografía sólida y documentación integrada. Sin embargo, GraphQL también puede resultar complejo y requerir más configuración y conocimientos específicos que REST.
  
  
• gRPC: rápido, con una mecanografía sólida, generación automática de código y transmisión bidireccional. gRPC se utiliza a menudo para la comunicación de microservicios. Pero como marco más nuevo, puede haber una curva de aprendizaje, y su formato de documentación es binario en lugar de legible por humanos. 

Al diseñar la API, el equipo también decidirá qué tipo de autenticación es adecuada (como OAuth 2.0) y si la API debe estar detrás de una API gateway.

Un documento de especificación describe la estructura, el comportamiento y la funcionalidad de una API de forma estandarizada. Ofrece una fuente única y confiable de información sobre cómo está construida la API, qué funciones tiene y cómo interactuar con ella. 

La especificación estandarizada más popular es la especificación OpenAPI, que permite a los desarrolladores definir rutas, métodos, parámetros, métodos de autenticación y más. OpenAPI se utiliza específicamente para las API REST y admite un conjunto de herramientas de código abierto llamadas Swagger, que ofrece generación de código, edición y creación automática de documentación.

Para GraphQL, la especificación equivalente es el esquema GraphQL, un contrato escrito con una mecanografía sólida en un lenguaje de definición de esquemas, o SDL, un formato legible por humanos. El ecosistema GraphQL ofrece algunas herramientas diferentes que aprovechan este esquema de maneras que ofrecen una funcionalidad similar a OpenAPI; por ejemplo, GraphiQL es un ecosistema de desarrollo integrado (IDE) en el navegador para que los desarrolladores lo utilicen como sandbox. 

Para gRPC, Protocol Buffers, o protobuf, es un formato de serialización y lenguaje de definición de interfaz (IDL) que sirve como el formato de archivo más utilizado para las especificaciones. Protobuf no ofrece pruebas interactivas, aunque hay interfaces de usuario (IU) web que lo permiten. 

En esta etapa, los desarrolladores comienzan a programar, siguiendo el plan de diseño de API descrito en el paso anterior. Se utiliza un sistema de control de versiones para realizar un seguimiento de las versiones y los cambios de código a lo largo del proceso de desarrollo.

El estándar de la industria para los sistemas de control de versiones es Git, una pieza de software de código abierto que rastrea los cambios en el código almacenado localmente en el dispositivo de un desarrollador. Los desarrolladores utilizan Git para crear, gestionar y realizar un seguimiento de los cambios en su código, pero luego necesitan un lugar para que ellos y otros puedan acceder a él. 

GitHub es el servicio de alojamiento de Git más popular, que ofrece niveles gratuitos y de pago, lo que permite el almacenamiento, la recuperación y la colaboración de repositorios de código Git. Existen alternativas para alojar repositorios Git, incluidos GitLab, AWS CodeCommit y Microsoft Azure Repos.

Las pruebas de API se llevan a cabo tanto durante como después de la fase de desarrollo de API; las pruebas continuas facilitan el desarrollo al revelar vulnerabilidades y necesidades, y permitir actualizaciones periódicas. 

Las pruebas unitarias consisten en aislar pequeñas partes del código y probarlas individualmente. En nuestro ejemplo de API de empresa de software, supongamos que el equipo necesita probar la respuesta a una solicitud para recuperar la información de un usuario. El comando GET está destinado a recuperar el nombre y la dirección de correo electrónico de un usuario a partir del número de identificación de ese usuario en una base de datos de clientes. Las pruebas unitarias implicarían garantizar que esta solicitud GET recupere la información prevista y que una solicitud de un ID de usuario inexistente devuelva un mensaje de error apropiado.

Las pruebas de integración suelen ejecutarse después de las pruebas unitarias y se utilizan para detectar problemas que estas últimas omiten. Las pruebas de integración ayudan a garantizar que varios componentes o servicios puedan comunicarse según lo previsto a través de la API. 

Volviendo a nuestro ejemplo, digamos que una característica de la API es que se envía un webhook, o notificación, de un sistema a otro en el caso de un determinado evento, como la incorporación de un nuevo cliente. Para asegurarse de que esto funcione, se configura una prueba de integración con un servidor falso que recibe una notificación y realiza la acción esperada cuando se agrega la información de un nuevo cliente al CRM. Este proceso se repite para todas las integraciones.

Las pruebas de contratos de API garantizan que una API haga lo que los usuarios esperan. El contrato suele construirse como un archivo de especificación de OpenAPI, que es un documento estándar legible por máquina que establece los elementos de la funcionalidad y las capacidades de una API. Un archivo de especificaciones de API suele estar escrito en JSON o YAML e incluye elementos como endpoint, métodos de autenticación, los formatos específicos de las solicitudes y respuestas aceptadas, metadatos y parámetros de entrada.

Evaluar el rendimiento de una API suele implicar evaluar su velocidad y eficiencia. En esta etapa, los evaluadores buscan medir el tiempo de respuesta de las consultas, las tasas de error, el uso de recursos (como el uso de CPU y memoria), la latencia y el rendimiento. Comprender el rendimiento de una API en esta etapa puede ayudar a detectar cuellos de botella o redundancias que puedan ralentizar la experiencia del usuario.

Las API se utilizan a menudo para transmitir datos confidenciales, lo que hace que las pruebas de seguridad sean un componente vital. Las pruebas de seguridad de API consisten, básicamente, en intentar vulnerar la API de diversas formas para garantizar su seguridad y estabilidad. Esos intentos pueden incluir pruebas de validación de entrada para garantizar que los datos solo se acepten cuando se ingresen en formatos preaprobados. 

Las pruebas de validación de entradas detectan diversos tipos de ataques. Los tipos comunes de ataques incluyen la inyección SQL, en la que los actores maliciosos insertan código malicioso en una aplicación. SQL es un lenguaje utilizado para comunicarse con bases de datos, y ciertos comandos SQL universales pueden desencadenar respuestas no autorizadas, como una lista de todos los usuarios. 

Otros métodos de prueba de seguridad incluyen pruebas de autenticación, que garantizan que las medidas de seguridad de identificación, como la biometría, funcionen correctamente, y pruebas de autorización, que garantizan que los usuarios solo puedan acceder a las características para las que están aprobados. 

Las pruebas de seguridad se realizan tanto durante como después de la fase de desarrollo, y las nuevas características de inteligencia artificial (IA) y automatización están mejorando la fuerza y precisión de estas pruebas. Las herramientas de pruebas de seguridad basadas en IA pueden generar pruebas automáticamente, escanear el código en busca de errores, analizar datos de rendimiento para ayudar a predecir problemas y señalar comportamientos anómalos, y mucho más.

En industrias como la atención médica y los servicios financieros, existen regulaciones, leyes y pautas para proteger la seguridad y la privacidad de los usuarios. Los ejemplos incluyen HIPAA (información de salud estadounidense),RGPD (información personal de la UE) y CCPA (información personal de California). 

Las pruebas de cumplimiento son aquellas que garantizan que la API cumple con todas las leyes y directrices aplicables. Por ejemplo, el RGPD otorga el “derecho al olvido”, lo que significa que los usuarios pueden solicitar la eliminación completa de sus datos sin demoras indebidas. Las pruebas de cumplimiento para una API que cumpla con el RGPD requerirían garantizar que se siga esta regla.

La etapa de despliegue es el lanzamiento de la API. Se probó su funcionalidad, seguridad y cumplimiento, y está lista para usarse. En la etapa de despliegue, la API se traslada del entorno de prueba al entorno de producción en tiempo real. Hay varios pasos involucrados en el despliegue de API.

Antes del despliegue, el equipo debe realizar otra revisión para garantizar que la infraestructura de soporte, la documentación de la API, el soporte al usuario, las estrategias de distribución y comunicación y los protocolos de monitoreo estén completos y listos para funcionar. Esta lista de verificación puede incluir escalado de servidores, configurar alertas y notificaciones, crear una página de preguntas frecuentes, enviar un anuncio a los clientes (o un anuncio público), entre otras cosas.

CI/CD, que significa integración continua/despliegue continuo, es un conjunto de prácticas que automatizan y agilizan los ciclos de desarrollo, pruebas y entrega de software. Es una práctica fundamental dentro de la metodología DevOps. Al igual que las aplicaciones de software, las API también se incorporan comúnmente en los pipelines de CI/CD para optimizar y automatizar el despliegue, las pruebas y la actualización de las API. 

Una API gateway es una capa de software que proporciona un único punto de entrada para que los clientes accedan a una variedad de servicios de backend o a múltiples instancias de un servicio de backend. Las API gateways pueden ofrecer varias ventajas:

• Simplicidad: los clientes solo necesitan realizar un seguimiento de una única URL de servicio en lugar de muchas.
  
  
• Equilibrio de carga: una organización puede distribuir el tráfico de un único servicio entre varias instancias para repartir la carga y evitar cuellos de botella en el rendimiento.
  
  
• Seguridad y gobernanza: se puede utilizar una puerta de enlace para aplicar protocolos estandarizados de seguridad y gobernanza en numerosas API. 
  
  
• Almacenamiento en caché: una puerta de enlace puede ayudar con el almacenamiento en caché almacenando datos a los que se accede con frecuencia en múltiples servicios. Esto ayuda a acelerar las respuestas y mejorar el rendimiento.

Las organizaciones a menudo emiten versiones beta para seleccionar usuarios con el fin de probar una API antes de lanzarla completamente al público. Esto permite a la organización encontrar y corregir errores, solicitar feedback, medir el rendimiento y promover la API en un entorno más seguro y controlado.

Una vez que la lista de verificación y los lanzamientos beta estén completos, es hora de “girar el interruptor” y desplegar completamente la API. Este proceso podría incluir el inicio de estrategias de distribución para informar aún más a los clientes internos o externos sobre la API y fomentar su uso. El proceso de distribución también puede incluir la publicación de guías de usuario y otras actividades de divulgación pública, la actualización de un sitio web o directorio de API y el ajuste de la configuración para permitir el acceso instantáneo en lugar de requerir autenticación privada.

Uno de los beneficios clave de comprender y planificar un ciclo de vida completo de API es garantizar que el monitoreo, la observabilidad y el mantenimiento sean un enfoque, desde el principio. El trabajo no termina con el lanzamiento; aún queda mucho por hacer. El monitoreo de API es un proceso continuo, diseñado para ver cómo funciona una API en el mundo real, en tiempo real. 

Las métricas clave para el monitoreo incluyen el tiempo de respuesta, o cuánto tiempo tarda la API en responder a las solicitudes; la tasa de error, o el porcentaje de solicitudes que fallan; el rendimiento y el tráfico, o la cantidad de solicitudes que la API puede manejar; y análisis de infraestructura, que mide la tensión y el estado de los servidores.

El elemento de mantenimiento surge en respuesta a los datos recopilados por las herramientas de monitoreo. El mantenimiento puede consistir en la corrección de errores, la optimización del rendimiento o incluso la incorporación de nuevas características o capacidades.

En nuestro ejemplo de CRM, las herramientas de monitoreo podrían detectar que la latencia es alta cuando los datos de los clientes se envían de una plataforma a otra; la fase de mantenimiento puede abordar esto reduciendo las redundancias de código, ajustando la configuración de almacenamiento en caché o reubicando los servidores para que estén más cerca de los clientes a los que atienden.

El final del ciclo de vida de una API es tan importante, dinámico e informativo como cualquier otra etapa.

El control de versiones es el proceso continuo de mantener la eficacia de una API mediante actualizaciones a lo largo de su vida útil. La clave del control de versiones es ofrecer cambios y mejoras sin interrumpir la funcionalidad existente para los usuarios establecidos. 

Para arreglos de errores simples y similares, las actualizaciones generalmente se emiten sin aplicar una nueva versión de API, ya que estos pequeños cambios se consideran “ininterrumpidos”. Pero para los cambios “que interrumpen”, en los que una nueva versión no es compatible con la versión que pretende reemplazar, es una buena práctica introducir el cambio como una nueva versión.

La comunicación, tanto temprana como frecuente, es clave para el control de versiones. Una práctica común es admitir versiones paralelas: la versión anterior permanece activa y funcional junto con la nueva versión, y los desarrolladores comunican los cambios para instar a los usuarios a migrar a la nueva versión. Una vez que todos los usuarios o una cantidad suficiente hayan migrado, se puede desactivar la versión anterior.

El retiro es la eliminación y desactivación permanentes de una API. No todas las API se retiran, pero es común que eventualmente se sustituya una API. Hay varias razones por las que una API podría retirarse:

• La nueva versión ofrece un rendimiento superior
• Las necesidades de cumplimiento o seguridad ya no se abordan adecuadamente 
• Cambios comerciales o financieros dentro de la organización
• Incompatibilidad con software más nuevo

Después del retiro, una API ya no será funcional. Pero hay algunas etapas que pueden ayudar a facilitar esta transición.

El retiro de una API requiere un análisis. ¿Es necesario retirar la API y por qué? ¿Cuál será la alternativa, si la hay? ¿Quién deberá estar al tanto del retiro inminente?

Por lo general, la organización anunciará que una API se retirará. Este anuncio incluye toda la información necesaria para los usuarios de la API, como por qué se produce este cambio, cuándo ocurrirá y qué acciones debe realizar el usuario, si corresponde. 

Entonces, la API queda oficialmente obsoleta. La API en este momento sigue operativa, pero no recibirá nuevas actualizaciones o características. El período de obsolescencia está diseñado para dar al usuario tiempo y concientización para realizar los ajustes necesarios.

El “ocaso” es cuando la API pública está completamente desactivada, momento en el que las solicitudes ya no se responderán y los clientes que intenten comunicarse con la API recibirán un mensaje de error. Es una buena práctica actualizar la documentación para reflejar este cambio y liberar espacio en el servidor u otra infraestructura que estuviera utilizando la API. 

Analizar en retrospectiva una API que ya no se utiliza puede resultar útil. Los equipos pueden analizar las lecciones aprendidas a lo largo del ciclo de vida completo de la API y cómo se pueden aplicar a proyectos futuros.