Header Ads Widget

Ticker

6/recent/ticker-posts

Qué significa la iniciativa de API abierta para el espacio de API

 

Que significa la iniciativa de API abierta para API space nordic apis

A medida que la comunidad de API comienza un nuevo año, lo hacemos con una variedad cada vez más amplia de formatos de descripción de API a nuestra disposición. Sin embargo, un desarrollo de finales del año pasado promete alterar este panorama al introducir una iniciativa destinada a estandarizar cómo se describen las API. En noviembre de 2015  se anunció la Open API Initiative , un consorcio respaldado por la Fundación Linux, con el objetivo expreso de " crear, desarrollar y promover un formato de descripción neutral para el proveedor ".

En el corazón de este formato se encuentra la especificación Swagger , que fue donada por el software SmartBear desde la versión 2.0 como base para la especificación abierta. SmartBear describe la estructura de gobierno ofrecida por  Open API Initiative como el siguiente paso lógico " para la especificación Swagger, dada su popularidad en la comunidad API. La  Iniciativa de API abierta también brinda un respaldo abierto de proveedores a Swagger (o la Especificación OpenAPI , bajo su nuevo nombre), y empresas como IBM y Microsoft figuran como  miembros de la Iniciativa de API abierta .

La  Open API Initiative ha sido determinada como un proyecto colaborativo por la Fundación Linux, que describen como " aprovechar el poder del desarrollo de código abierto para impulsar la innovación a una velocidad y escala inigualables ". También incorporará un modelo de gobierno abierto implementado con un "Comité de Desarrolladores Técnicos" que " mantendrá y desarrollará la especificación, así como también involucrará a los usuarios para que realicen comentarios para informar el desarrollo ".

Avanzar hacia la estandarización

Claramente, la Open API Initiative (OAI) es un paso importante hacia la estandarización de la descripción de API , respaldada por un formato ampliamente utilizado y popular que debería dar a la iniciativa una base sólida para establecer una amplia base de usuarios. Como señala la Fundación Linux: “ Dado que las descargas de herramientas Swagger y Swagger casi se triplicaron durante el último año, se considera el marco de trabajo de código abierto más popular para definir y crear API RESTful”. Junto con una comunidad grande y activa, el soporte abierto de los proveedores proporciona un impulso adicional al uso de Swagger y, por lo tanto, la aceptación de la comunidad: ya existe soporte de facto (SmartBear cita el ejemplo de IBM Watson y la descripción de la API de Watson usando Swagger), pero El soporte formal para Swagger por parte de los proveedores involucrados finalmente dará como resultado la adopción de Swagger en los marcos y utilidades de los proveedores, lo que facilitará que sus clientes lo utilicen como consumidor y proveedor de API con las herramientas que elijan.

Un mejor soporte del proveedor para Swagger obviamente trae consigo la capacidad para que los desarrolladores de API y los consumidores de API puedan automatizar mejor las prácticas de desarrollo : como vimos en la publicación del blog sobre API Transformer , la automatización de actividades como la ejecución de casos de prueba contra API bien descritas permite a los departamentos de TI Sea más proactivo en la forma en que producen e ingieren API. La estandarización en torno a un formato de descripción de API dado dará a los desarrolladores la capacidad de agregar automáticamente nuevas especificaciones a medida que se publican, generar nuevas bibliotecas que acceden a una API determinada y realizar análisis de impacto mucho antes de que un ser humano se dé cuenta de que la API ha cambiado.

Más información: Cómo automatizar el control de versiones en toda la plataforma API-SDK

En el futuro, los cambios de API podrían detectarse e ingerirse de forma completamente autónoma, con una organización consumiendo nuevas versiones de API a medida que se publican sin la participación del desarrollador. Naturalmente, este tipo de comportamiento no es específico del uso de la especificación Swagger, pero es probable que se adopten tales prácticas cuando las API se describen utilizando un formato de especificación consistente y bien conocido que aumenta la probabilidad de resultados deterministas cuando se usa para generar código o documentación. . Junto con tecnologías como Consul , la estandarización en una especificación de descripción de API presenta la oportunidad para que el concepto de descubrimiento de servicios alcance su máximo potencial (un ejemplo de un enfoque para el descubrimiento de servicios es el trabajo de API.guru en la creación de una Wikipedia de API REST en formato Swagger). Implementar el modelo de descubrimiento de servicios de una manera que permita a las aplicaciones seleccionar API que presenten un "mejor ajuste" basado en capacidad o categorización depende de un buen grado de estandarización, y la Especificación OpenAPI podría ofrecer esto a las aplicaciones consumidoras.

linux_foundation_logo

Finalmente, el apoyo de la Fundación Linux presenta la oportunidad para que la Especificación OpenAPI se desarrolle más rápidamente , dados los recursos que la Fundación puede aportar y el estado de la OAI como Proyecto Colaborativo. Los ejemplos de otros proyectos de colaboración exitosos incluyen CloudFoundry y la Fundación Node.js . Si la Fundación puede realmente impulsar la especificación OAI y lograr un éxito similar, entonces debería haber desarrollos interesantes para la nueva especificación de OpenAPI Specification.

Consulte también nuestro artículo sobre formato REST que compara Swagger, API Blueprint y RAML

Posibles obstáculos de la iniciativa de API abierta

Si bien la OAI es un desarrollo emocionante, el entusiasmo por el proyecto debe atenuarse con una dosis de realidad. Si bien la OAI beneficiará claramente al crecimiento continuo de la economía API , llevará tiempo demostrar hasta qué punto los grandes proveedores involucrados en el consorcio intentarán ejercer su influencia y, por lo tanto, cómo evolucionará la Especificación OpenAPI.

Además, la estructura real del Comité de Desarrolladores Técnicos aún no se ha anunciado, incluidos los procesos que utilizarán para impulsar el desarrollo y la participación de la comunidad: si la implementación de la carta de gobierno no se aborda de manera abierta y colaborativa, su potencial que el comité se vea envuelto en disputas sobre la dirección de la OAI. Uno debería mirar el ejemplo de Bitcoin XT y cuán dañina puede ser la discordia para el desarrollo de la tecnología cuando no existen las medidas apropiadas dentro de un proceso de gobernanza para asegurar una representación justa para todos. Sin embargo, los Proyectos Colaborativos de la Fundación Linux han tenido éxito en unir a las comunidades tecnológicas y uno esperaría que esto continúe con la Especificación OpenAPI. El estatuto de gobernanza de la OAI también incluye específicamente una Junta de Supervisión Técnica que debería ayudar con la mediación, ya que gestionará “ conflictos, violaciones de procedimientos o directrices y cualquier problema transversal o de alto nivel que no se pueda resolver en el TDC ”.

SmartBear también se ha comprometido a continuar expandiendo tanto la comunidad Swagger como las herramientas de apoyo, que incluyen Swagger CodeGen, UI y Editor. Si bien esto solo puede ser beneficioso para la adopción de Swagger en su nueva apariencia como la Especificación de OpenAPI, a largo plazo las necesidades de la comunidad pueden diferir de los objetivos de la OAI: los miembros más grandes del consorcio pueden desear influir en la especificación de sus propios casos de uso específicos. Queda por ver si las necesidades de la comunidad y las necesidades de los proveedores se volverán discordantes a medida que avance el crecimiento de la OAI.

Finalmente, está la cuestión de todas las demás especificaciones de descripción de API que tienen el apoyo de otros proveedores en la economía: RAML , IO Docs , API Blueprint y OData , por nombrar solo algunos. Independientemente del éxito de la OAI, es poco probable que las comunidades y los proveedores que mantienen, respaldan y defienden estas especificaciones se unan a las filas de la OAI de inmediato o en el corto plazo. En cuanto a las diferencias entre formatos, a algunos no les gusta el hecho de que la especificación OpenAPI " no permite describir correctamente la carga útil del cuerpo de la solicitud ".

El éxito de la OAI dependerá en gran medida de su estrategia para abordar estas especificaciones alternativas y determinar cómo incorporarlas o asegurarse de que sean interoperables con la OAI. También está la cuestión de cómo algunos de los miembros del consorcio abordan el hecho de las especificaciones que han admitido en el pasado, y su propia ruta de migración a la Especificación OpenAPI: Microsoft es el ejemplo más pertinente de esto, dada su larga participación con OData. como una especificación de descripción de API. Cualquiera que sea la estrategia, es necesario asegurarse de que se puedan incorporar otras especificaciones de alguna manera. Sin él, el objetivo principal de la iniciativa, el de crear un formato neutral para el proveedor en la economía de API, Es probable que se bloquee desde el principio, ya que el tema de la inclusión no se extenderá a toda la comunidad. Además, otros formatos de especificación y versiones anteriores de Swagger (lo más pertinente es la versión 1.2) estarán disponibles durante algún tiempo, por lo que la ruta de migración debe ser tanto mantenible como sostenible.

Más reflexiones: ¿Cuál es el futuro del espacio API?

Conclusión

open-api-iniciativa-logo-nordic-apis

A primera vista, la Open API Initiative tiene el potencial de ser un desarrollo enormemente valioso para la economía de las API, agregando el soporte de muchos de los principales proveedores y la Fundación Linux a una especificación de descripción de API muy popular que la comunidad de API puede admitir. Sin embargo, hay claramente una serie de factores que determinarán si el iniciado tiene éxito en proporcionar una metodología de descripción holística que pueda trascender otros conjuntos de herramientas y proveedores. En nuestra publicación sobre el desarrollo de API independientes de la descripción, aludimos al hecho de que puede ser difícil establecer un lenguaje de descripción unificado para todas las API y para algunos miembros de la comunidad de API puede no ser deseable en absoluto. Si la Open API Initiative puede reunir tanto la especificación Swagger como otras especificaciones importantes de descripción de API en un marco único e interoperable, tiene el potencial de ofrecer un enfoque incomparable para la descripción del servicio que hará de la economía de API una propuesta aún más convincente.

Publicar un comentario

0 Comentarios