API First strategy
- Onesait Platform
Introducción
API First se define como una estrategia que trata al usuario de la API como el usuario primario de la aplicación. Por ello, la aproximación “API First” impone una API completa, responsiva y bien documentada. Como podemos suponer, deberá existir una importante colaboración entre los desarrolladores y consumidores de la API, ya que todos ellos tendrán una perspectiva diferente y ayudarán a diseñar una gran API.
Marco de desarrollo
A continuación veremos el marco de desarrollo entre un marco más tradicional y API First:
El marco más tradicional, situado a la izquierda, se prioriza el desarrolla de la API para posteriormente crear las APIs y posteriormente que lo consuma un equipo de front-end o usuarios.
Mientras que el marco de desarrollo de API First, situado a la derecha, lo primero que se define son las interfaces de las APIs con datos mockeados para que en paralelo todos los participantes del proyecto puedan consumirla y realizar su desarrollo correspondiente.
Como bien podemos deducir por la descripción de marco de desarrollo, API First ofrece ventajas frente a un diseño tradicional, por destacar las más importantes:
Agilidad en el desarrollo
Time-to-market
Mejoría de la experiencia del cliente al estar más involucarado en el proceso.
Ciclo de vida
Desde Arquitectura proponemos un ciclo de vida para la construcción de microservicios que cumplan con la arquitectura API First y además damos una serie de aceleradores para facilitar su implementación que veremos a continuación.
Primeramente veamos los pasos del ciclo de vida.
Contrato
Como hemos visto en la introducción, lo primero que se hace es el diseño de la APIs donde entrarían a definirlo todos los actores involucrados, como pueden ser PO, desarrolladores back-end, desarrolladores front-end, clientes, usuarios que consumirán dicha API, etc.. En este punto de definición y diseño de la API nos apoyaremos en OpenAPI (OAS3) que nos permitirá especificar la interfaz de forma fácil y sencilla para todos los involucrados y además nos permitirá cumplir con los estandar de Arquitectura.
Además, podremos llevar un fácil y útil control de versiones de las definiciones OpenAPI 3 que vayamos realizando para ir comprobando los cambios que se vayan produciendo, aquí nos apoyaremos en GIT.
Y para finalizar, se irá iterando sobre el diseño de la API hasta que sea aceptada por todos los actores involucrados, evitando así, o al menos disminiyendo al mínimo, cambios posteriores que afecten al desarrollo y al tiempo de entrega.
Código
Con el punto anterior satisfecho, y con la definición de la API en OpenAPI 3, podemos directamente generar el código a través de nuestro Initializr.
Como se puede comprobar por la imagen anterior se crea un microservicio con la capa controlador y servicio, además del modelo definidos en el diseño de la API, acelerando así el desarrollo del microservicio y cumpliendo con lo aceptado por los distintos actores involucrados.Test de contrato
Como punto complementario al ciclo de vida de desarrollo de la API desde Arquitectura proponemos los test de contrato. Los test de contratos o de interfaz nos permiten verificar los esquemas de solicitud y de respuesta de una API y su comportamiento.
Los test de contrato se puede aplicar: •En aplicaciones en construcción en las que se siga la filosofía API First mediante el diseño y mockeado de los servicios, permitiendo a las aplicaciones consumidoras engancharse a estos servicios antes de que los backend estén construidos •En aplicaciones en funcionamiento para comprobar flujos de funcionalidad críticos de una manera periódica en el pipeline y así minimizar las consecuencias de un fallo al detectarlos de forma reactiva |
Como se puede ver en la imagen anterio, en este parte están involucrados Postmant, Newman y Jenkin, además, desde Arquitectura disponibilizamos un módulo descargable desde nuestro Initializr para realizar esta tareas de forma más fácil. Se puede ver en más detalle aquí.