The Benefits of an API-First Approach to Building Microservices (Ventajas de un enfoque «api-first» en la creación de microservicios)

Las API son el tejido conectivo de las aplicações nativas de la nube: el medio por el cual los microservicios componentes de una aplicación se comunican. A medida que las aplicações crecen y escalan, también lo hace el número de microservicios y API. Si bien este es un resultado inevitable en la mayoría de los casos, crea desafíos importantes para los equipos de operaciones de plataforma responsables de garantizar la confiabilidad, la escalabilidad y la seguridad de las aplicações modernas. A este problema lo llamamos proliferación de API y escribimos sobre ello en una publicación de blog anterior.

Como primer intento de resolver la proliferación de API, una organización podría intentar utilizar un enfoque de arriba hacia abajo implementando herramientas para el descubrimiento y la remediación automatizados de API. Si bien esto es efectivo en el corto plazo, a menudo impone una carga indebida a los equipos responsables de crear y operar API y microservicios. O bien tienen que reelaborar los microservicios y las API existentes para abordar problemas de seguridad y cumplimiento o pasar por un arduo proceso de revisión para obtener las aprobaciones necesarias. Es por esto que muchas grandes organizaciones de software adoptan un enfoque descentralizado que utiliza gobernanza adaptativa para brindarles a los desarrolladores la autonomía que necesitan .

En lugar de implementar salvaguardas de último momento, un enfoque de abajo hacia arriba para abordar el problema es más eficaz a largo plazo. Los equipos que crean y operan API para diferentes microservicios y aplicações son los primeros en involucrarse y, a menudo, comienzan adoptando un enfoque de API primero para el desarrollo de software en su organización.

¿Qué es «API-first»?

Las API existen desde hace décadas. Pero ya no son simplemente “interfaces de programación de aplicação ”. En esencia, las API son interfaces para desarrolladores. Como cualquier interfaz de usuario, las API necesitan planificación, diseño y pruebas. API-first implica reconocer y priorizar la importancia de la conectividad y la simplicidad en todos los equipos que operan y utilizan API. Prioriza la comunicación, la reutilización y la funcionalidad para los consumidores de API, que casi siempre son desarrolladores.

Hay muchos caminos hacia API-first , pero un enfoque de desarrollo de software basado en el diseño es el objetivo final para la mayoría de las empresas que se embarcan en un viaje API-first. En la práctica, este enfoque significa que las API están completamente definidas antes de la implementación. El trabajo comienza con el diseño y la documentación de cómo funcionará la API. El equipo se basa en el artefacto resultante, a menudo denominado contrato API , para saber cómo implementar la funcionalidad de la aplicación.

Explore técnicas de diseño para respaldar un enfoque API-first para el desarrollo de software que sea duradero y flexible en el Capítulo 1 del libro electrónico Mastering API Architecture de O'Reilly, cortesía de NGINX.

El valor de API-First para las organizaciones

Una estrategia API-first suele ser ideal para las arquitecturas de microservicios porque garantiza que los ecosistemas de aplicação comiencen su vida como sistemas modulares y reutilizables. La adopción de un modelo de desarrollo de software basado en API ofrece importantes beneficios tanto para los desarrolladores como para las organizaciones, entre ellos:

• Mayor productividad del desarrollador : los equipos de desarrollo pueden trabajar en paralelo y actualizar las aplicações backend sin afectar a los equipos que trabajan en otros microservicios que dependen de las API de las aplicações. La colaboración suele ser más sencilla a lo largo del ciclo de vida de la API, ya que cada equipo puede consultar el contrato de API establecido.
• Experiencia de desarrollador mejorada : el diseño API-first prioriza la experiencia del desarrollador al garantizar que una API sea lógica y esté bien documentada. Esto crea una experiencia fluida para los desarrolladores al interactuar con una API. Descubra por qué es tan importante que los equipos de Operaciones de Plataforma consideren la experiencia del desarrollador de API<.htmla>.
• Gobernanza y seguridad consistentes : los arquitectos de la nube y de la plataforma pueden organizar el ecosistema de API de manera consistente incorporando reglas de seguridad y gobernanza durante la fase de diseño de API. Esto evita las costosas revisiones necesarias cuando se descubren problemas más adelante en el proceso del software.
• Calidad de software mejorada : diseñar las API primero garantiza que se cumplan los requisitos de seguridad y cumplimiento en las primeras etapas del proceso de desarrollo, mucho antes de que la API esté lista para implementarse en producción. Al tener menos necesidad de corregir fallas de seguridad en la producción, sus equipos de ingeniería de operaciones, calidad y seguridad tienen más tiempo para trabajar directamente con los equipos de desarrollo para garantizar que se cumplan los estándares de calidad y seguridad en la fase de diseño.
• Tiempo de comercialización más rápido : con menos dependencias y un marco consistente para la comunicación entre servicios, los diferentes equipos pueden crear y mejorar sus servicios de manera mucho más eficiente. Una especificación de API consistente y legible por máquina es una herramienta que puede ayudar a los desarrolladores y a los equipos de Platform Ops a trabajar mejor juntos .

En general, adoptar un enfoque API-first puede ayudar a una empresa a construir una arquitectura de microservicios más flexible, escalable y segura.

Cómo puede ayudar la adopción de una especificación API común

En el panorama típico de API y microservicios empresariales, hay más componentes en juego de los que un equipo de operaciones de plataforma puede controlar día a día. Adoptar una especificación de API estándar y legible por máquina ayuda a los equipos a comprender, monitorear y tomar decisiones sobre las API que operan actualmente en sus entornos.

La adopción de una especificación API común también puede ayudar a mejorar la colaboración con las partes interesadas durante la fase de diseño de API. Al producir un contrato de API y formalizarlo en una especificación estándar, puede garantizar que todas las partes interesadas estén de acuerdo sobre cómo funcionará una API. También facilita compartir definiciones y capacidades reutilizables entre equipos.

Hoy en día existen tres especificaciones de API comunes, cada una de las cuales admite la mayoría de los tipos de API:

• OpenAPI : descripciones JSON o YAML de todas las API web y webhooks
• AsyncAPI : descripciones JSON o YAML de API basadas en eventos
• Esquema JSON : descripciones JSON de los objetos de esquema utilizados para las API

Las API REST constituyen la mayor parte de las API en producción actualmente, y la Especificación OpenAPI es el estándar para escribir una definición de API para una API REST. Proporciona un contrato legible por máquina que describe el funcionamiento de una API determinada. La especificación OpenAPI cuenta con un amplio respaldo en diversas herramientas de gestión de API y pasarelas de API, incluyendo NGINX. El resto de este blog se centrará en cómo usar la especificación OpenAPI para implementar algunos casos de uso importantes.

La especificación OpenAPI es un formato de código abierto para definir API en JSON o YAML. Puede incluir una amplia gama de características de API, como lo ilustra el siguiente ejemplo de API simple. Aquí, una simple solicitud HTTP GET devuelve una lista de artículos de una lista de compras imaginaria.

OpenAPI: 3.0.0 información:
versión: 1.0.0
título: API de lista de compras
Descripción: Una API de ejemplo para ilustrar la especificación OpenAPI

servidores:
URL: https://api.example.io/v1

rutas:
/lista:
obtener:
descripción: Devuelve una lista de artículos de tu lista de la compra.
Respuestas:
        '200':
Descripción: Lista devuelta correctamente
Contenido:
Esquema:
Tipo: Matriz
Ítems:
Tipo: Objeto
Propiedades:
Nombre_del_ítem:
Tipo: Cadena

Las definiciones que siguen la especificación OpenAPI son legibles tanto para humanos como para máquinas. Esto significa que existe una única fuente de verdad que documenta cómo funciona cada API, lo que es especialmente importante en organizaciones con muchos equipos que crean y operan API. Por supuesto, para administrar, gobernar y proteger las API a escala, debe asegurarse de que el resto de las herramientas en su plataforma de API (puertas de enlace de API, portales para desarrolladores y seguridad avanzada) también admitan la especificación OpenAPI.

Profundice en cómo diseñar API REST utilizando la especificación OpenAPI en el Capítulo 1 de Mastering API Architecture .

Beneficios de adoptar una especificación API común

El uso de una especificación API común, como la Especificación OpenAPI, tiene varias ventajas:

• Interoperabilidad mejorada : una especificación común legible por máquina significa que diferentes sistemas y clientes pueden consumir y usar el contrato API. Esto facilita que los equipos de Platform Ops integren, administren y supervisen arquitecturas complejas.
• Documentación consistente : el contrato de API está documentado en un formato estándar, incluidos los puntos finales, los formatos de solicitud y respuesta, y otros detalles relevantes. Muchos sistemas pueden usar el contrato para generar documentación completa, brindando claridad y facilitando que los desarrolladores comprendan cómo usar la API.
• Mejores pruebas : las especificaciones de API se pueden usar para generar y ejecutar pruebas automáticamente, lo que puede ayudar a garantizar que la implementación de la API se adhiera al contrato y funcione como se espera. Esto puede ayudar a identificar problemas con una API antes de que se publique en producción.
• Seguridad mejorada : las herramientas de seguridad avanzadas pueden utilizar la especificación OpenAPI para analizar el tráfico de API y el comportamiento del usuario. Pueden aplicar seguridad positiva<.htmla> al verificar que las solicitudes de API cumplan con los métodos, puntos finales y parámetros admitidos por el punto final de la API. El tráfico no conforme se bloquea de forma predeterminada, lo que reduce la cantidad de llamadas que sus microservicios deben procesar.
• Evolución más sencilla : las especificaciones de API pueden ayudar a facilitar la evolución del contrato de API y de la aplicação en sí a lo largo del tiempo al proporcionar una forma clara y estándar de documentar y comunicar cambios en formatos legibles para máquinas y humanos. Cuando se combina con prácticas de control de versiones adecuadas, esto ayuda a minimizar los impactos de los cambios de API en los consumidores de API y garantiza que una API siga siendo compatible con versiones anteriores.

En general, el uso de una especificación de API común puede ayudar a mejorar la interoperabilidad, la documentación, las pruebas, la seguridad y la evolución gradual de una API.

Cómo NGINX apoya el desarrollo de software API-First

NGINX proporciona un conjunto de herramientas livianas y nativas de la nube que facilitan la operación, el monitoreo, la administración y la protección de las API a escala. Por ejemplo, API Connectivity Manager , parte de F5 NGINX Management Suite , proporciona un único plano de gestión para sus operaciones de API. Con él podrás configurar y gestionar puertas de enlace API y portales para desarrolladores. Como herramienta API-first, cada función es accesible a través de API REST, lo que hace que la automatización e integración de CI/CD sea fácil para los equipos de DevOps .

Utilizando la especificación OpenAPI, puede utilizar los productos NGINX para:

• Publicar API en la puerta de enlace de API
• Generar documentación de API para el portal para desarrolladores
• Aplicar seguridad positiva para proteger los puntos finales de la API

Publicar API en API Gateway

API Connectivity Manager utiliza la especificación OpenAPI para optimizar la publicación y gestión de API. Los desarrolladores de API pueden publicar API en la puerta de enlace de API mediante la interfaz de usuario de NGINX Management Suite o la API REST totalmente declarativa. Las API se añaden a la puerta de enlace como proxies de API, que contienen todas las configuraciones de entrada, backend y enrutamiento que la puerta de enlace de API necesita para dirigir las solicitudes de API entrantes al microservicio de backend. Puede utilizar la API REST para implementar y administrar API como código mediante la creación de scripts de automatización de CI/CD simples con herramientas como Ansible.

Para obtener instrucciones completas sobre el uso de la especificación OpenAPI para publicar una API, consulte la documentación de API Connectivity Manager .

Generar documentación de API para el portal para desarrolladores

Mantener la documentación suele ser un dolor de cabeza para los equipos de API. Pero la documentación desactualizada en los portales para desarrolladores también es un síntoma importante de la proliferación de API. API Connectivity Manager utiliza la especificación OpenAPI para generar automáticamente documentación y publicarla en el portal para desarrolladores, lo que ahorra tiempo a los desarrolladores de API y garantiza que los consumidores de API siempre puedan encontrar lo que necesitan. Puede cargar archivos de especificación OpenAPI directamente a través de la interfaz de usuario de API Connectivity Manager o la API REST.

Para obtener instrucciones completas sobre la publicación de la documentación de API en el portal para desarrolladores, consulte la documentación de API Connectivity Manager .

Aplicar seguridad positiva para proteger los puntos finales de la API

También puede utilizar la especificación OpenAPI para verificar que las solicitudes de API a la puerta de enlace API de NGINX Plus cumplan con lo que admite una API. Al aplicar seguridad positiva (un modelo de seguridad que define lo que está permitido y bloquea todo lo demás), puede evitar que solicitudes maliciosas examinen sus servicios de backend en busca de posibles vulnerabilidades.

Al momento de escribir este artículo, no se puede usar API Connectivity Manager para configurar NGINX App Protect WAF ; esta funcionalidad estará disponible más adelante en 2023. Sin embargo, puede utilizar Instance Manager (otro módulo de NGINX Management Suite) y la especificación OpenAPI para escribir políticas personalizadas para su WAF. Para obtener información adicional, consulte la documentación de NGINX App Protect WAF y Instance Manager .

Obtenga más información sobre la seguridad de API y el modelado de amenazas, y cómo aplicar la autenticación y la autorización en la puerta de enlace de API en el Capítulo 7 de Mastering API Architecture .

resumen

Un enfoque API-first para crear microservicios y aplicações puede beneficiar a su organización de muchas maneras. Alinear los equipos en torno a la especificación OpenAPI (u otra especificación API común que sea legible tanto para humanos como para máquinas) ayuda a posibilitar la colaboración, la comunicación y las operaciones entre equipos.

Las aplicações modernas operan en entornos complejos nativos de la nube. La adopción de herramientas que permitan un enfoque API-first para operar API es un paso fundamental para hacer realidad su estrategia API-first. Con NGINX puedes usar la especificación OpenAPI para administrar tus API a escala en equipos y entornos distribuidos.

Comience una prueba gratuita de 30 días de NGINX Management Suite , que incluye acceso a API Connectivity Manager , NGINX Plus como puerta de enlace de API y NGINX App Protect para proteger sus API.