¿En qué consiste el ciclo de vida de una API?

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

No existe un ciclo de vida universal para los creadores de API. Puede que vea diferentes variaciones según las fuentes, pero el ciclo de vida generalmente incluye las siguientes etapas: planificar, diseñar, desarrollar, probar, implementar, monitorizar y retirar.

Las plataformas de gestión de API suelen utilizarse para ayudar a organizar tareas a lo largo del ciclo de vida de una API, y para centralizar la estrategia, el gobierno, la documentación y los directorios de las API en todo el entorno de TI. Muchas plataformas incluyen capacidades de análisis avanzadas y herramientas para el descubrimiento y la monetización de API que ayudan a las organizaciones a aprovechar al máximo sus API.

La consideración y comprensión de todo el ciclo de vida de la API ayuda a los equipos de desarrollo a asignar recursos de manera más eficiente, crear plazos realistas para la entrega, mantener informadas a todas las partes interesadas durante todo el proceso y garantizar que las API cumplan con los requisitos comerciales. Básicamente, 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 las API comprende varias etapas clave, que comienzan con la planificación preliminar y concluyen, a menudo, aunque no siempre, con su retirada o sustitución. A modo de ejemplo, consideremos una empresa de software que decide desarrollar una API para sincronizar los datos de sus clientes con herramientas empresariales como los sistemas de gestión de tiques, los sistemas de contabilidad, las plataformas de gestión de proyectos y otras.

La creación de una API comienza por responder a algunas preguntas fundamentales: ¿por qué se necesita esta API?, ¿a quién va dirigida?, ¿cómo se utilizará? y ¿cómo se medirá su é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 moverse de manera fluida 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 empresariales de la API
• Describen cómo esta API responderá a las necesidades del negocio
• Se aseguran de que no haya API existentes u otros productos disponibles en los mercados de integración nativa que puedan hacer lo que se requiere (en esencia, confirman que es necesario desarrollar esta API)
• Delimitan claramente qué aplicaciones y plataformas dependerán de la API y cómo se integrará esta con los flujos de trabajo existentes

A continuación, el equipo debería analizar los posibles usuarios y los casos de uso. ¿Es únicamente 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?

Fijar un plazo 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 característica, que deban cumplirse? ¿Hay equipos de seguridad o de cumplimiento legal u otras partes interesadas que deban aprobar antes de que se pueda implementar 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 en el 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 debe crearse la API para satisfacer los requisitos detallados en la fase de planificación. 

El equipo debe tomar decisiones de diseño sobre el 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 ventajas e inconvenientes. 

• REST: simple, intuitivo y omnipresente, pero no ideal para consultas complejas y no ofrece tipado fuerte.
  
  
• GraphQL: eficiente, con escritura sólida y documentación integrada. Sin embargo, GraphQL también puede ser complejo y requerir más configuración y conocimientos específicos que REST.
  
  
• gRPC: rápido, con tipado fuerte, generación automática de código y transmisión bidireccional. gRPC se utiliza a menudo para la comunicación de microservicios. Sin embargo, al tratarse de un marco de trabajo relativamente nuevo, puede suponer una curva de aprendizaje, y el formato de su documentación es binario, en lugar de legible para el ser humano. 

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

Un documento de especificaciones describe la estructura, el comportamiento y la funcionalidad de una API de forma estandarizada. Proporciona una única fuente fiable con información sobre cómo se ha creado la API, qué puede hacer 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 mucho más. OpenAPI se utiliza específicamente para las API REST y es compatible con 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.

En el caso de GraphQL, la especificación equivalente es el esquema de GraphQL, un contrato fuertemente tipado escrito en lenguaje de definición de esquemas (SDL), un formato legible para los humanos. El ecosistema de GraphQL ofrece varias herramientas que aprovechan este esquema de formas que proporcionan una funcionalidad similar a la de OpenAPI; por ejemplo, GraphiQL es un entorno de desarrollo integrado (IDE) que funciona directamente en el navegador y que los desarrolladores pueden utilizar como entorno aislado. 

En el caso de gRPC, Protocol Buffers, o protobuf, es un formato de serialización y un lenguaje de definición de interfaces (IDL) que constituye el formato de archivo más utilizado para las especificaciones. Protobuf no ofrece pruebas interactivas, aunque existen IU web que permiten realizar este tipo de pruebas. 

En esta etapa, los desarrolladores comienzan la codificación, 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 los sectores 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 rastrear los cambios en su código, pero luego necesitan un lugar donde puedan acceder ellos y los demás. 

GitHub es el servicio de alojamiento 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, como GitLab, AWS CodeCommit y Microsoft Azure Repos.

Las pruebas de API se realizan tanto durante como después de la fase de desarrollo de API; las pruebas continuas ayudan al 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 la API de una empresa de software, digamos que el equipo necesita probar la respuesta de 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 asegurarse de 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 las pruebas unitarias pasan por alto. Las pruebas de integración ayudan a garantizar que múltiples componentes o servicios puedan comunicarse según lo previsto a través de la API. 

Si volvemos a nuestro ejemplo, supongamos que una de las características de la API es que se envía un webhook, o notificación, de un sistema a otro cuando se produce un determinado evento, como la incorporación de un nuevo cliente. Para garantizar que esto funcione, se configura una prueba de integración con un servidor ficticio que recibe una notificación y lleva a cabo la acción prevista cuando se añade 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 que haga. archivo de especificación OpenAPI, un documento estándar legible por máquina que describe los elementos de la funcionalidad y las capacidades de una API. Un archivo de especificación de API suele estar escrito en JSON o YAML e incluye elementos como endpoints de la API, métodos de autenticación, los formatos específicos de las solicitudes y respuestas aceptables, metadatos y parámetros de entrada.

Evaluar el rendimiento de la API suele implicar evaluar su velocidad y eficiencia. En esta etapa, los encargados de las pruebas 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 revelar cuellos de botella o redundancias que pueden ralentizar la experiencia del usuario.

Las API se utilizan a menudo para transmitir datos sensibles, por lo que las pruebas de seguridad son un componente vital. Las pruebas de seguridad de API intentan esencialmente romper la API de varias maneras para garantizar la seguridad y la estabilidad. Esos intentos pueden incluir pruebas de validación de entradas para garantizar que los datos solo se acepten cuando se ingresen en formatos aprobados previamente. 

Las pruebas de validación de entradas buscan varios tipos de ataques. Los tipos comunes de ataques incluyen la inyección SQL, en la que actores malintencionados 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 pruebas de seguridad incluyen las pruebas de autenticación, que garantizan el correcto funcionamiento de las medidas de seguridad de identificación, como la biometría, y las pruebas de autorización, que garantizan que los usuarios solo puedan acceder a las características para las que están autorizados. 

Las pruebas de seguridad se llevan a cabo tanto durante como después de la fase de desarrollo, y las nuevas características de inteligencia artificial (IA) y la automatización están mejorando la solidez y la precisión de estas pruebas. Las herramientas de pruebas de seguridad con IA pueden generar pruebas automáticamente, escanear 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 sectores como la sanidad y los servicios financieros, existen reglamentos, leyes y directrices para proteger la seguridad y la privacidad de los usuarios. Algunos ejemplos son la HIPAA (información sanitaria en EE. UU.), el RGPD (datos personales en la UE) y la CCPA (datos personales de California). 

Las pruebas de cumplimiento son pruebas 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 demora indebida. Las pruebas de cumplimiento para una API que cumpla con el RGPD requerirían garantizar que se respete esta norma.

La etapa de implementación es el lanzamiento de la API. Se ha probado su funcionalidad, seguridad y cumplimiento, y está listo para su uso. En la fase de implementación, la API pasa del entorno de pruebas al entorno de producción. Hay varios pasos involucrados en la implementación de las API.

Antes de la implementación, el equipo debe llevar a cabo otra revisión para asegurarse de que la infraestructura de apoyo, la documentación de la API, la asistencia al usuario, las estrategias de distribución y comunicación, y los protocolos de monitorización estén todos completados y listos para su puesta en marcha. Esta lista de comprobación podría incluir el escalado de servidores, la configuración de alertas y notificaciones, la creación de una página de preguntas frecuentes, el envío de un comunicado a los clientes (o un comunicado público) y otras tareas.

La CI/CD (integración continua/implementación continua) es un conjunto de prácticas que automatizan y optimizan 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 agilizar y automatizar la implementación, las pruebas y la actualización de las API. 

Una puerta de enlace de API 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 varias instancias de un servicio de backend. Las puertas de enlace de API pueden ofrecer varias ventajas:

• Simplicidad: los clientes solo tienen que hacer un seguimiento de una única URL de servicio en lugar de muchas
  
  
• Equilibrio de la 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 gobierno: se puede utilizar una puerta de enlace para aplicar protocolos estandarizados de seguridad y gobierno a través de múltiples 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 varios servicios. Esto ayuda a acelerar las respuestas y mejorar el rendimiento.

Las organizaciones suelen emitir 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 completada la lista de comprobación y los lanzamientos beta, es hora de “pulsar el interruptor” e implementar la API por completo. Este proceso puede incluir la puesta en marcha de estrategias de distribución para informar mejor a los clientes internos o externos sobre la API y fomentar su uso. El proceso de distribución también podría 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 un directorio de API y el ajuste de la configuración para permitir el acceso instantáneo en lugar de requerir una autenticación privada.

Uno de los beneficios clave de comprender y planificar un ciclo de vida completo de la API es garantizar que la monitorización, la observabilidad y el mantenimiento sean un enfoque, desde el principio. El trabajo termina en el momento del lanzamiento; aún queda mucho por hacer. La monitorización 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 la monitorización incluyen el tiempo de respuesta, o cuánto tarda la API en responder a las solicitudes; tasa de error, o el porcentaje de solicitudes que fallan; el rendimiento y el tráfico, o el número de solicitudes que puede gestionar la API; 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 monitorización. El mantenimiento puede consistir en corregir errores, optimizar el rendimiento o incluso añadir nuevas características o capacidades.

En nuestro ejemplo de CRM, las herramientas de monitorización podrían detectar que la latencia es elevada cuando los datos de los clientes se envían de una plataforma a otra; en la fase de mantenimiento se puede solucionar este problema reduciendo las redundancias en el código, ajustando la configuración del almacenamiento en caché o reubicando los servidores para que estén más cerca de los clientes a los que prestan servicio.

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 consiste en ofrecer cambios y mejoras sin afectar a la funcionalidad existente para los usuarios habituales. 

En el caso de simples correcciones de errores y similares, las actualizaciones suelen publicarse sin aplicar una nueva versión de la API, ya que estos pequeños cambios se consideran “sin ruptura”. Sin embargo, en el caso de cambios “con ruptura”, en los que una nueva versión no es compatible con la versión anterior a la que pretende sustituir, es una buena práctica introducir el cambio como una nueva versión.

La comunicación, tanto al principio como a menudo, 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 o suficientes usuarios hayan migrado, se puede desactivar la versión anterior.

La retirada definitiva consiste en la eliminación permanente y la desactivación de una API. No todas las API se retiran, pero es habitual sustituirlas con el tiempo. Hay varias razones por las que se puede retirar una API:

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

Una vez retirada, una API dejará de funcionar. Sin embargo, hay algunas etapas que pueden facilitar esta transición.

La retirada de una API requiere un debate. ¿Es necesario retirar la API y por qué? ¿Cuál sería la alternativa, si la hubiera? ¿A quiénes se debe informar de la inminente retirada?

Por lo general, la organización anuncia que una API está a punto de retirarse. Este anuncio incluye toda la información necesaria para los usuarios de la API, como por qué se produce este cambio, cuándo se producirá 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 periodo de obsolescencia está diseñado para dar al usuario tiempo y conciencia para realizar los ajustes necesarios.

La fecha de retirada es el momento en que la API pública se desactiva por completo; a partir de ese momento, ya no se responderá a las solicitudes y los clientes que intenten acceder a la API recibirán un mensaje de error. Es una buena práctica actualizar la documentación para reflejar este cambio y liberar cualquier espacio en el servidor u otra infraestructura que la API estuviera utilizando. 

Realizar un análisis retrospectivo de una API retirada puede resultar muy útil. Los equipos pueden analizar las lecciones aprendidas a lo largo del ciclo de vida completo de la API y cómo pueden aplicarse a proyectos futuros.