Header Ads Widget

Ticker

6/recent/ticker-posts

¿Qué debe considerar antes de la adopción de OpenAPI?


 La especificación OpenAPI es adorada y su utilidad la ha visto sujeta a una adopción generalizada en los últimos años. Está claro que muchos ven el valor de la especificación OpenAPI y ven el valor en su adopción.

Como con cualquier tendencia, hay una cierta cantidad de consideración que se debe pagar antes de adoptar la carta blanca de la solución. Si bien muchos adoptantes ciertamente están haciendo su debida diligencia, merece un poco de discusión dentro del esquema más amplio de la industria de API abordar qué esperar con OpenAPI antes de sumergirse.

Con ese fin, analicemos la especificación OpenAPI. Discutiremos qué es exactamente, de dónde vino y hacia dónde se dirige. Veremos algunos pros y contras de adoptar la especificación, así como algunas sugerencias sobre qué considerar antes de emprender la implementación.

¿Qué es la especificación OpenAPI?

Especificación de OpenAPI

La especificación OpenAPI se puede utilizar para asegurar y acelerar el ciclo de vida de la API.

OpenAPI , conocido por su nombre más formal como OpenAPI Specification , es una especificación e iniciativa para la creación de archivos de interfaz legibles por máquina que se utilizan para describir, producir, consumir y visualizar servicios web RESTful . Junto a la especificación, existen herramientas como el conjunto de herramientas Swagger para generar código, documentación , casos de prueba y más. Actualmente, la especificación OpenAPI está curada y supervisada por Open API Initiative .

El progenitor de la especificación OpenAPI fue la especificación Swagger. Swagger comenzó a desarrollarse a principios de 2010 y, en marzo de 2015, SmartBear Software adquirió la definición. En noviembre de ese año, SmartBear anunció la creación de una nueva organización bajo el patrocinio de la Fundación Linux llamada Open API Initiative. La organización estaba compuesta por algunos actores bastante importantes en la industria, incluidos Google, Microsoft e IBM, todos enfocados en el desarrollo de este concepto abierto.

Para ayudar en el desarrollo, SmartBear donó la especificación Swagger, donde se renombró como Especificación OpenAPI y se trasladó a un nuevo repositorio de GitHub . En 2017, se lanzó la versión 3.0 de la Especificación OpenAPI y MuleSoft, el principal contribuyente de RESTful API Modeling Language (RAML) se unió al comité de Especificación OpenAPI para permitir la generación de documentos OAS desde RAML.

Con un pedigrí tan histórico, debería ser obvio que la especificación OpenAPI llegó para quedarse , y su desarrollo parece expandirse a medida que cada nuevo socio se une a la organización de la especificación OpenAPI. Todo el enfoque de Swagger estaba en optimizar y sincronizar el flujo de trabajo de actualización y permitir una generación de documentación y código de cliente y servidor más dinámicos, y por esta razón, OpenAPI es muy atractivo para el desarrollador promedio.

Leer más: ¿Qué hay de nuevo en OpenAPI v3?

OpenAPI frente a "API abierta"

Antes de discutir la especificación de OpenAPI, primero debemos diferenciar dos términos muy comunes y combinados. Cuando se habla de este tema, existe la "Especificación OpenAPI" y el concepto de "API abierta".

El concepto de una API abierta es que la API debe estar compuesta principalmente por módulos de código abierto, o al menos, debe estar abierta a inspección y utilización. Una API abierta se puede bifurcar, desarrollar en cosas nuevas o cambiar y transformar de forma gratuita. El código abierto es un objetivo noble, pero hay una gran diferencia entre eso y la idea de la Especificación OpenAPI, que es fundamentalmente una interacción guiada y un control de versiones establecido para el desarrollo.

A medida que avanzamos, esto debería ser una consideración importante: aunque algunas API abiertas más públicas pueden usar la especificación OpenAPI, OpenAPI no es sinónimo de API abiertas.

Beneficios de adoptar la especificación OpenAPI

Entonces, ¿qué hace que OpenAPI sea una propuesta tan atractiva? Existe el valor obvio que ya hemos discutido, por supuesto: OpenAPI está respaldado por algunos grandes actores de la industria y, como tal, representa una mente compartida en la industria que es realmente valiosa .

Tener el respaldo de tantos actores importantes también sugiere que, con el tiempo, la implementación es estable . Es menos probable que se abandone o se fusione con otras soluciones, dado lo prolífico que ha sido el desarrollo de la implementación hasta este momento. También se debe considerar que OpenAPI es una especificación abierta respaldada por algunos de los diseñadores de bases de código patentados más grandes; de esa manera, se ha sugerido que OpenAPI probablemente proporcionará algún tipo de co-funcionalidad e interfaz en el futuro si el desarrollo continúa en el futuro. como ha sido.

Quizás el argumento más fuerte para la especificación OpenAPI es su experiencia en Swagger . Swagger ha existido durante tanto tiempo y tiene una comunidad y una base de apoyo tan grandes que, cuando se convirtió en la Especificación OpenAPI, incorporó a algunos de los mejores talentos y miembros de la comunidad más prolíficos a la nueva solución. Esto es muy similar con su tasa de adopción, ya que Swagger fue ampliamente adoptado y considerado; debido a esto, OpenAPI también ha tenido una adopción bastante amplia.

Además, basándose en el amplio soporte de idiomas de Swagger, la especificación OpenAPI se considera independiente del idioma . Para la mayoría de los desarrolladores, esto es un regalo del cielo.

Para obtener una descripción más técnica de la adopción de OpenAPI, lea: 5 formas en que la especificación de OpenAPI estimula la agilidad de la API

Posibles inconvenientes de la adopción de OpenAPI

Por supuesto, con cualquier tecnología, hay algunas consideraciones que deben internalizarse y considerarse como parte de un plan de adopción más amplio. Para OpenAPI, esto puede ser especialmente cierto entre los proveedores de API de hipermedia.

En primer lugar, la calidad independiente del lenguaje mencionada anteriormente de OpenAPI es excelente para la inclusión, pero también introduce una gran complejidad en la incorporación de marcos específicos del lenguaje, API de terceros y extensiones basadas en servidor. Algunas soluciones solo están diseñadas para funcionar dentro de lenguajes específicos y, si bien se podría argumentar que esto es un inconveniente de dichas soluciones, el hecho es que muchos proveedores no tienen otra opción al respecto. Obligarlos a redirigir sus soluciones para implementar la especificación es una venta difícil, especialmente cuando la Especificación de OpenAPI señala que una API no tendrá que ser reescrita para utilizar la especificación.

Un problema importante con la especificación de OpenAPI es que, en muchos sentidos, es simplemente un paso adicional para solucionar lo que de otra manera serían problemas importantes en el diseño centrado en el esquema . La especificación OpenAPI crea un gran marco para el desarrollo, pero esencialmente funciona como un atajo al conocimiento y comprensión reales. En otras palabras, para los desarrolladores que no estén familiarizados con sus conceptos, OpenAPI puede funcionar como un parche en lugar de un conjunto de herramientas.

Kin Lane, The API Evangelist, lo expresó mejor en su blog :

La gente necesita aprender sobre patrones de diseño consistentes para sus solicitudes y respuestas. Piense en poner en orden su casa de esquemas. Piense en la negociación de contenido de manera coherente. […] Para usted (el gurú de los hipermedia), OpenAPI es redundante, sin sentido e innecesario. Para muchos otros, les proporciona un plan saludable a seguir y les permite aprender conocimientos de la red y buenas prácticas de diseño de API en los incrementos que su trabajo diario y el presupuesto actual lo permiten.

Eso no quiere decir que exista necesariamente un problema con OpenAPI en sí, pero al considerar la adopción, los proveedores deben considerar si la adopción es como un marco para mejores API o como un parche para superar su falta de comprensión sobre las mejores prácticas y el desarrollo.

Incluso con todo eso dicho, también debe tenerse en cuenta que la especificación OpenAPI en sí no es compatible con todos los tipos de API. Algunos servicios no se pueden describir en la forma en que se comporta la Especificación. Como señala la documentación en el sitio web oficial :

La especificación OpenAPI no requiere la reescritura de las API existentes. No requiere vincular ningún software a un servicio; es posible que el servicio que se describe ni siquiera sea propiedad del creador de su descripción. Sin embargo, requiere que las capacidades del servicio se describan en la estructura de la Especificación OpenAPI. OpenAPI no puede describir todos los servicios; esta especificación no pretende cubrir todos los estilos posibles de API REST .

Actualizaciones en el mundo OpenAPI

Entonces, ¿hacia dónde se dirige OpenAPI? Para ver el valor de la especificación OpenAPI, podemos echar un vistazo a algunas de las noticias más recientes de OpenAPI .

Un hito importante este año fue que RepreZen se unió a la Iniciativa OpenAPI . RepreZen son los creadores del lenguaje de modelado de recursos RAPID-ML y, como tal, su incorporación a la organización significa que los desarrolladores ahora tienen un gran editor con el que trabajar en OAS. El CEO Ted Epstein resumió sus esfuerzos como moverse fuera del enfoque marco en el que OpenAPI ha operado hasta ahora y más hacia la integración total:

Este es un modelo genérico para el contrato de API como código, que utiliza la especificación de API abierta no solo para la documentación y no solo para una plantilla de generación de código de una sola vez que le brinda algo de código de andamiaje. Esto realmente está integrando completamente la especificación de la API en su código. Cuando trabaja con la especificación OpenAPI, definitivamente es un nivel más alto de abstracción. Por cada línea de código OpenAPI que escribe, obtiene 20 líneas de código ejecutable [Con RepreZen,] obtiene esta abstracción pero también obtiene una visibilidad completa de su código.

La propia especificación OpenAPI experimentó un movimiento importante en 2017, con el lanzamiento de la versión 3.0.0 . Al agregar soporte para describir devoluciones de llamada, mejorar el manejo de documentos de varias partes, agregar la capacidad de expresar relaciones entre operaciones como enlaces, y más, 3.0.0 marca un objetivo importante para la implementación, y sugiere que algunos pasos importantes aún están en el bosque.

El director de tecnología de SmartBear Software y el presidente de la junta de la OAI, Ole Lensmar, resumió el lanzamiento como así en los comunicados oficiales de relaciones públicas :

El lanzamiento de este formato de tercera generación es un hito importante para nuestra comunidad. Las actualizaciones realizadas son totalmente impulsadas por el usuario y el uso y eso juega un papel muy importante en el éxito de la especificación. Una de las cosas más poderosas de esta versión es su capacidad para impulsar el ciclo de vida completo de la API.

La especificación OpenAPI ha experimentado grandes avances en su adopción. Lensmar continuó diciendo que expandió su crecimiento de miembros en un factor de 4 en los últimos 18 meses, que ahora incluye 42Crunch, Adobe, Cloud Elements, Oracle Apiary, Red Hat, Tyk, Intento y más miembros junto con otros 20 socios. Su uso también se está filtrando en nuevos sectores, con un creciente interés por parte del gobierno y las organizaciones de tecnología de la salud y de salud. Este crecimiento masivo indica que la industria está lista para OpenAPI y, obviamente, ve el valor de tal especificación.

Conclusión

En última instancia, la especificación OpenAPI es extremadamente valiosa y los proveedores de API deben considerarla como una opción sólida para el caso de uso dado. La implementación debe considerarse con tanto peso como se debe; de ​​lo que estamos hablando aquí no es solo una especificación, sino un plan y un marco fundamentales que está respaldado por una gran variedad de grandes nombres que se amplía cada año. .

En consecuencia, si bien OpenAPI debe considerarse tan valioso como realmente es, la debida diligencia debe ser la primera y más importante consideración antes que nada.

Publicar un comentario

0 Comentarios