Header Ads Widget

Ticker

6/recent/ticker-posts

¿Es OpenAPI la puerta de entrada al éxito de DevOps?

 

No es un eufemismo decir que OAS (Especificación OpenAPI) ha cambiado la forma en que muchos desarrolladores diseñan sus API , con su formato estandarizado que permite una adopción e implementación más fácil de las API.

Sin embargo, el verbo usado en esa última oración es revelador: habla de cómo los desarrolladores "diseñan" sus API, en lugar de cómo las "potencian" o las "utilizan". En nuestra cumbre de API de Austin 2019, Vincenzo Chianese de Stoplight habló extensamente sobre cómo los desarrolladores podrían implementar la especificación OpenAPI de maneras más involucradas.

¿Y si, por ejemplo, pudiera usarse para impulsar el software de producción con una puerta de enlace API? A continuación, veremos cómo se podría usar algo destinado a estandarizar el diseño en la producción e implementación de API.

Reloj Vincenzo Chianese de la luz de parada presente en el 2019 Austin Cumbre API: .

OpenAPI, DevOps y Automatización

Lo primero es lo primero, echemos un vistazo rápido a aclarar los términos que usaremos a lo largo de este artículo:

"La especificación OpenAPI define una descripción de interfaz estándar, independiente del lenguaje de programación para las API REST, que permite que tanto humanos como computadoras descubran y comprendan las capacidades de un servicio".

En otras palabras, OEA tiene como objetivo estandarizar elementos de producción de API con la esperanza de simplificar su consumo. La literatura oficial de la OEA continúa especificando que:

Los casos de uso de documentos de definición de API legibles por máquina incluyen, entre otros: documentación interactiva; generación de código para documentación, clientes y servidores; y automatización de casos de prueba.

Tenga en cuenta la introducción de la automatización aquí, que es algo que aparece nuevamente en la información sobre los conceptos detrás de DevOps :

DevOps es un conjunto de prácticas que automatiza los procesos entre el desarrollo de software y los equipos de TI, para que puedan construir, probar y lanzar software de forma más rápida y confiable.

Inmediatamente, vemos cierta correlación entre los objetivos de OAS y DevOps: automatización, consistencia y comunicación mejorada entre diferentes partes. Quizás esto es lo que hizo que Vincenzo mirara OpenAPI y se preguntara "¿qué pasa con el lado operativo de mi API?"

OpenAPI y puertas de enlace

Para tales casos de uso, incluido ...

  • Implementación segura de una nueva sección de API
  • Establecer una sección de API como obsoleta
  • Cambios en los requisitos de seguridad
  • Cambios en las reglas de validación
  • Redireccionamientos

… Vincenzo pensó inmediatamente en recurrir a una API Gateway. "Ese suele ser el mejor lugar para hacer este tipo de automatización", dice, y destaca algunas de las razones por las que se sentía como el lugar para incursionar con OpenAPI y DevOps:

  • Superficie de configuración limitada de API Gateways
  • Casi 1: 1 coincide con el archivo de descripción de OpenAPI
  • Algunas soluciones se pueden configurar de forma declarativa

Cuando se trata de servicios propietarios, existe cierta variación en la medida en que los proveedores se alinean con OEA. Vincenzo explica, por ejemplo, que "AWS API Gateway admite muchos casos de uso que no se pueden expresar con OAS, por lo que tienen muchas extensiones".

Sin embargo, ese no es necesariamente el caso de otras API Gateways, ya que Microsoft API Management tiene algunas extensiones, mientras que Apigee Edge no tiene extensiones documentadas. Esto en sí mismo podría ser útil para ayudarlo a determinar qué puerta de enlace es la más adecuada para usted, dependiendo de qué tan cerca quiera seguir con OAS.

Sin embargo, en el ámbito del código abierto, Vincenzo dice que las cosas no son tan optimistas. Él declara que por ahora, al menos, “OpenAPI no es un ciudadano de primera clase cuando se trata de puertas de enlace API de código abierto” como Express Gateway, Kong o Tyk.io.

Señala el apoyo escaso / inconsistente cuando los usa como una razón para esto (aunque reconoce algunas mejoras recientes aquí), así como el hecho de que no son la herramienta adecuada para el trabajo cuando OAS no cubre ciertas funciones deseadas.

Curiosamente, esto puede tener algunos paralelos con las API estrictamente controladas que se ajustan a las recomendaciones de la OEA, mientras que se requiere un pensamiento más innovador con las API públicas de código abierto debido a su naturaleza colaborativa.

¿Es suficiente con OpenAPI?

Vincenzo comparte un breve experimento durante su charla, en el que hace ajustes al funcionamiento de una API. ¿Una de las cosas notables que destaca después de la demostración? “No tuve que tocar una sola línea de código; este no es un código que deba cambiar, sino una cosa declarativa de la que debo ocuparme ".

Para algunos, serán buenas noticias. Sin duda, se remonta a la idea de "construir una cultura de colaboración entre equipos que históricamente funcionaron en silos relativos", que es uno de los conceptos centrales de DevOps.

Para maximizar la efectividad de usar OpenAPI en conjunto con DevOps, Chianese recomienda que:

  • Utilice una puerta de enlace API
  • Asegúrese de que su API exponga exactamente lo que está disponible en el archivo OpenAPI
  • Usa una solución declarativa
  • Abstenerse de utilizar extensiones de cliente

Sin embargo, al concluir su charla, habló sobre las limitaciones de OpenAPI. Específicamente, dice que "los documentos OpenAPI por sí solos no son suficientes para describir todos los aspectos de una API". ¿Su solución sugerida? Que la especificación OpenAPI necesita ser expandida.

Desafortunadamente, la adopción generalizada de OpenAPI significa que esta solución parece mucho más simple de lo que realmente es ...

El problema de expandir OpenAPI

Cuando se trata de expandir OpenAPI, los usuarios tienen una de dos opciones:

  1. Espere a que los creadores de OpenAPI se basen en la especificación existente: ¡roll-on OAS v4! - para cubrir el terreno necesario (pero la naturaleza de código abierto de la especificación significa que incluso esto es complicado).
  2. Construya sobre la especificación de una manera que les convenga, sabiendo que las adiciones “oficiales” a la OEA pueden verse diferentes a las reglas y formatos que han implementado.

Ninguna de ellas es una solución ideal y explica por qué la consistencia sigue siendo difícil de encontrar incluso entre las API que se ajustan a OpenAPI en su mayor parte.

Un problema importante aquí es que la mayoría de la OEA ya es considerada muy completa, y ampliar la especificación aún más podría parecer restrictivo. Esto es algo que, por razones obvias, SmartBear quiere evitar: cuanto más restrictivo es un marco, más desarrolladores sienten la necesidad de desviarse de él.

A medida que pasa el tiempo, OpenAPI continúa evolucionando y la especificación se ajustará a conceptos como DevOps según sea necesario. Mientras tanto, sigue siendo un juego de experimentación y pruebas. Aún así, hay muchos desarrolladores de API que dirían que siempre es la etapa más emocionante de todos modos.

Publicar un comentario

0 Comentarios