Fotolia
Conozca las cinco etapas del ciclo de vida de una API
Las API no son solo un componente que puede configurar y olvidar. Los desarrolladores deben planificar, crear, implementar y monitorear API para mantenerlas alineadas con las necesidades del negocio, así como saber cuándo es el momento de retirarlas.
Las API ayudan a que diversos productos de software interoperen y trabajen juntos. Pero las API también son software, y cada una tiene un ciclo de vida que la lleva de la cuna a la tumba.
Una API es un software que proporciona un medio de comunicación o interacción entre otros componentes o sistemas de software. Por ejemplo, cuando una empresa programa una cita para un cliente, la aplicación de programación puede usar una API de Google para enviar un recordatorio de cita al Google Calendar del cliente.
Las API a menudo juegan un papel en los procesos iterativos de desarrollo de software, que se mueven a un ritmo rápido. Sin embargo, los desarrolladores deben mantener la estabilidad de la API mientras las aplicaciones asociadas se someten a actualizaciones y cambios frecuentes. La publicación continua de nuevas versiones de una API puede ser problemática para el software y los servicios que dependen de ella.
Echemos un vistazo más de cerca a las API y consideremos las etapas básicas de un ciclo de vida de la API.
El ciclo de vida para una API
Aunque las opiniones difieren sobre las partes reales del ciclo de vida de una API, esta discusión utiliza cinco fases clásicas: planificación, desarrollo, pruebas, implementación y retiro.
1. Fase de planificación
Cualquier proyecto de desarrollo de API debe comenzar con la planificación y el diseño. Haga que los miembros del equipo de negocios identifiquen qué servicios y capacidades debe exponer una API. Documente las necesidades comerciales específicas y refina los objetivos iniciales de la API en un conjunto integral de requisitos funcionales y no funcionales.
Aquí hay un ejemplo de requisitos para una API: Un servicio de mapeo necesita centrar el mapa en la ubicación de un usuario. Del mismo modo, un usuario debe poder seleccionar una ubicación de destino ingresando una dirección física u otros datos. Esto significa que la aplicación debe poder examinar los datos de ubicación y conectarse con el sistema GPS de un dispositivo móvil.
Una vez que se establecen los requisitos de la API, los equipos de desarrollo pueden tomar decisiones de diseño informadas sobre convenciones de nomenclatura, estilos arquitectónicos y los protocolos específicos a utilizar. La planificación y el diseño deben dar como resultado una especificación de API que describa los métodos y operaciones admitidos por la interfaz, así como también cualquier restricción técnica.
El paradigma del restaurante
Una de las formas más fáciles para entender qué es una API y cómo funciona es pensar en ella como un menú en un restaurante. Un menú muestra comida, bebida y otras opciones para ordenar, y es el medio principal para que un comensal interactúe con lo que ofrece el restaurante. Cuando los comensales piden un menú, no necesitan saber nada sobre el equipo de cocina, el personal o cómo funciona el restaurante. Al igual que los clientes, el software puede «ordenar» lo que necesita mirando la API sin necesidad de comprender la aplicación que esta llama.
Un restaurante también actualizará los menús periódicamente para agregar nuevas ofertas o eliminar las impopulares. Si el contenido o el formato de un menú cambian con demasiada frecuencia, los comensales pueden confundirse y frustrarse porque no pueden encontrar lo que quieren. Pero, mientras un menú sea razonablemente estable, no necesariamente le importa al cliente si la cocina, el personal u otras operaciones del restaurante cambian detrás de escena. Nuevamente, al igual que un cliente en un restaurante, una pieza de software que solicita puede experimentar fallas si no puede encontrar fácilmente los recursos que necesita a través de la API de la que depende.
2. Fase de desarrollo
Las API se pueden escribir en muchos lenguajes de programación, incluidos PHP, Python, Ruby, .NET, C #, Java y Perl. La codificación y las pruebas pueden requerir numerosas iteraciones, pero los equipos de desarrollo no deberían lanzar una API a producción antes de que sea estable. En última instancia, el desarrollo de API necesita excelentes habilidades de planificación, codificación y prueba, junto con la disciplina necesaria para minimizar los cambios de la API orientada al cliente.
El desarrollo de API puede ser realizado por un solo desarrollador, pero es manejado con mayor frecuencia por un equipo de desarrollo de API separado y dedicado. Un enfoque de equipo permite que múltiples desarrolladores accedan, creen y mantengan la cartera de API de la organización de una manera cuidadosamente controlada. Además, varios desarrolladores facilitan la creación de la documentación, los casos de prueba e incluso algunos de los materiales de marketing que se necesitarían para que las API públicas sean exitosas para el negocio.
Dado que es un esfuerzo de equipo, múltiples desarrolladores necesitarán acceder y mantener cooperativamente sus API. Todo el equipo API debería poder ver e interactuar con el código API, la documentación y los archivos de prueba. Esto también hace que sea importante implementar controles integrales de búsqueda y control de versiones, lo que ayuda a los desarrolladores autorizados a ubicar las API por criterios, como proyecto y versión.
La planificación del desarrollo de API siempre debe rodear estas tres consideraciones:
- Cómo rastreará el uso, el rendimiento, los errores y otras métricas importantes de la API.
- Componentes de seguridad, en particular la autorización OAuth 2.0 y la validación de la clave de API.
- Problemas de rendimiento y accesibilidad, como la asfixia y la limitación de velocidad, para garantizar un acceso adecuado de la API.
3. Fase de prueba
Los desarrolladores deben probar a fondo cada iteración de la API para la funcionalidad, el rendimiento y la aceptación del usuario. Los evaluadores pueden enviar resultados insatisfactorios a los desarrolladores para construir y refinar aún más el código de la API.
Las pruebas funcionales validan que cada característica o función opere según lo previsto. Utilice maquetas y versiones de prueba para evaluar la funcionalidad de la API en comparación con su especificación. Las pruebas funcionales también enfatizan el enfoque en las capacidades de seguridad y manejo de errores que aseguran que la API esté protegida contra fallas o ataques.
Las pruebas de rendimiento evalúan el rendimiento de la API bajo carga. Muchas API están sujetas a tráfico errático y condiciones de carga impredecibles. Las métricas de pruebas de rendimiento miden qué tan bien funciona la API bajo cargas pesadas, como el tiempo que lleva responder a una determinada solicitud de aplicación.
La prueba de aceptación rastrea el uso de la API y determina si cumple con el propósito comercial previsto. Las pruebas de aceptación pueden revelar cualquier requisito nuevo que pueda surgir de un cambio en el proceso comercial o en la API misma. Puede ayudar a identificar posibles cambios en las funciones existentes que podrían hacer que la API sea más útil. Por ejemplo, en los casos en que los datos pueden pasarse hacia o desde la API, las pruebas de aceptación pueden revelar la necesidad de pasar más o diferentes datos como argumento de parámetro.
4. Fase de implementación
Una vez que una API es estable y segura, está lista para la producción. Sin embargo, al igual que con muchos productos de software, la versión inicial de una API puede actuar como una segunda etapa de pruebas de rendimiento y validación.
Por ejemplo, los desarrolladores pueden lanzar una nueva API en un entorno de implementación azul/verde, donde los desarrolladores prueban la versión de API más nueva con el software sin afectar la versión en vivo. Idealmente, cuando los desarrolladores hayan preparado su última versión, la API está lista para el entorno de producción completo. Una parte clave de este proceso es recopilar métricas que rastrean el rendimiento de la API, como la cantidad de errores que experimenta.
Los desarrolladores deben minimizar las interrupciones causadas por una nueva versión de API. Una API bien escrita debe incluir una función de llamada de versión que pueda recuperar una versión válida conocida para ponerla en producción en caso de que la nueva resulte inadecuada.
Los cambios de API que corrigen errores o mejoran el rendimiento generalmente no afectarán las llamadas y respuestas de API. Sin embargo, los nuevos parámetros y argumentos para la autenticación, u otros cambios de diseño fundamentales, pueden obligar a los usuarios a realizar actualizaciones de software antes de que puedan acceder a la nueva versión de API.
5. Fase de retiro
Los desarrolladores pueden ampliar y actualizar las API a lo largo del tiempo para mejorar el valor comercial, pero cada API acumula costos de infraestructura y soporte a medida que pasa el tiempo. Finalmente, los equipos de software retiran las API antiguas y las versiones antiguas de las API para no desperdiciar los recursos que las respaldan.
Como tal, una empresa necesita planificar diligentemente la ruta de migración de una versión de API a otra y aprender a mantener varias versiones de API a la vez mientras refina nuevas versiones. Los equipos de software necesitan un plan de fin de vida para suspender las API sin afectar drásticamente las operaciones diarias.
El monitoreo es una gran parte de este proceso de retiro, especialmente cuando se trata de rastrear la edad y el historial de una API. Por ejemplo, una empresa puede descubrir que algunas API han quedado prácticamente sin usar en 90 a 120 días. Sin embargo, todavía están alojadas en la infraestructura, consumen recursos y crean costos. Es por eso que el rastreo de estas API es una parte tan esencial de un plan de retiro de API eficaz y equilibrado.
