Header Ads Widget

Ticker

6/recent/ticker-posts

Cómo los esquemas de API hacen obsoletos los conectores

 Especificaciones como OpenAPI brindan una solución a los problemas de conectores obsoletos al brindar la opción de crear servicios de integración generados por máquina a pedido, escribe David Brown, fundador de TORO Cloud.





Los conectores, tal como los utiliza una plataforma de integración de aplicaciones empresariales (EAI) o iPaaS, pronto podrían volverse redundantes a medida que estas plataformas comiencen a reemplazarlos con servicios generados por máquinas impulsados ​​por esquemas API. El beneficio para los usuarios es que ya no dependen de la plataforma para ofrecer un conector para la API que les gustaría consumir, proporcionando al usuario una mayor independencia para integrar cualquier API que elijan.

Cuando un desarrollador desea integrar una API web con otro sistema o aplicación, normalmente tiene dos opciones. Escriba laboriosamente el código a mano o utilice una plataforma de integración de aplicaciones, a menudo denominada iPaaS.

Tradicionalmente, las plataformas de integración han proporcionado un conector único para todas y cada una de las API que admite la plataforma. Estos conectores facilitan la comunicación entre la plataforma y un sistema o API de terceros.

Como los clientes de estas plataformas dependían de que la plataforma ofreciera un conector para la API que querían integrar, significaba que había una especie de carrera entre los proveedores que podían ofrecer la mayor cantidad de conectores.

Pero, ¿qué pasa si el proveedor no proporciona un conector para la API que le gustaría consumir? O, ¿qué pasa si su conector está desactualizado? Los lenguajes de descripción de API como OpenAPI proporcionan a los proveedores de plataformas de integración una solución a este problema que puede eliminar el conector y permitir al usuario consumir la API directamente con servicios de integración generados dinámicamente.

¿Qué es un conector?

Las plataformas EAI utilizan conectores para permitir la comunicación entre la plataforma y una API. El conector envuelve la API en un lenguaje que la plataforma de integración puede entender, lo que permite que los usuarios de esa plataforma puedan acceder a la API.

Las plataformas EAI hacen que los usuarios finales sean más productivos al proporcionar modelos visuales y declarativos para describir los componentes para las integraciones. Estos componentes incluyen puntos finales, protocolos, formatos de datos, transformación de datos y flujos de trabajo. Una plataforma de integración puede reducir drásticamente el trabajo pesado requerido que de otro modo tendría que codificarse a mano para realizar esas funciones repetitivas. También reduce la posibilidad de errores humanos y produce servicios de integración que son fácilmente reutilizables y detectables.

Cada plataforma de integración tiene su propia forma de describir estos modelos declarativos para la integración. Un conector es un contenedor que permite a la plataforma de integración traducir la operación de cada API a un formato que la plataforma comprenda.

El problema con los conectores

Los conectores suelen estar escritos a mano. Su desarrollo requiere mucho tiempo y, como resultado, son costosos de escribir y mantener. Esto limita la cantidad de conectores que un proveedor puede producir de manera viable. Dada la economía, los conectores se crean primero para los proveedores de software más populares. Es posible que las API de proveedores más pequeños y las líneas especializadas de aplicaciones comerciales no sean compatibles. Dada la proliferación y el crecimiento exponencial de las API, es imposible mantenerse al día con los editores de API cuando se escriben conectores a mano.

Además, los proveedores de API cambian con frecuencia sus API, especialmente cuando los servicios aún están madurando. Esto sucede con más frecuencia de lo que la mayoría de la gente cree. Algunos editores son menos disciplinados acerca de las versiones correctas de los cambios en sus API para garantizar que los cambios importantes solo se introduzcan en actualizaciones importantes. Como resultado, cambios menores en una API pueden romper un conector. Idealmente, debería ser posible seguir usando el conector con la última versión compatible de una API. Sin embargo, en la práctica, si la API no utiliza prácticas de control de versiones disciplinadas, es posible que se vea obligado a esperar una actualización del conector para adaptarse al cambio radical.

Mientras tanto, es posible que la API que está consumiendo haya lanzado una operación que estaba anticipando con impaciencia. Si el conector que está utilizando no es compatible con la nueva función, de nuevo depende del proveedor de la plataforma EAI para lanzar una actualización del conector.

¿La solución a estos problemas? Esquemas de API.

La evolución del esquema de API

Con las API, hablamos de hacerlas visibles . Con esto, nos referimos a simplificar que un consumidor de una API comprenda el propósito, las operaciones, los protocolos, la autenticación de las API, cómo formatear una solicitud y la estructura y carga útil de una respuesta.

La forma más común de lograr esto es la documentación basada en web . Dicha documentación está dirigida al consumo humano, incluidos fragmentos de código para desarrolladores que trabajan en varios lenguajes de programación. En última instancia, se asume que un humano será el que interprete la documentación y cree los servicios necesarios para consumir la API.

Algunos editores de API producen un kit de desarrollo de software (SDK) para facilitar el consumo de la API en un lenguaje de programación determinado, como Java o .NET. Un SDK facilita el consumo de una API al escribir una integración a mano. Sin embargo, no cambia el hecho de que una plataforma de integración tendría que producir un conector SDK. Si bien la mayoría de los editores de API proporcionan algún tipo de documentación basada en web, relativamente pocos proporcionan un SDK.

Esquemas de API y servicios generados por máquinas

Los lenguajes de descripción de API se diseñaron para resolver el desafío de hacer que una API sea detectable con documentación estructurada que sea legible tanto por humanos como por máquinas. La salida de un lenguaje de descripción de API, el esquema de API, se produce en JSON o YAML y describe una API de forma compatible con los estándares.

Los esquemas de API crean documentación estructurada y legible por máquina que permite que una API sea más visible. Una plataforma de integración de aplicaciones empresariales puede crear servicios generados por máquina para cada operación de API bajo demanda leyendo un esquema de API directamente.

Si una plataforma EAI puede leer un esquema de API y generar servicios de integración a partir de él, no es necesario esperar a que la plataforma de integración admita una API específica. Siempre que la API proporcione un esquema de API, la plataforma debería poder consumirlo. Si la API cambia, simplemente puede importar el esquema de API actualizado, generar nuevos servicios y comenzar a consumir las nuevas operaciones de inmediato.

Como la mayoría de los estándares emergentes, cuando surgieron los primeros lenguajes de descripción de API, no había un consenso claro sobre un formato que se convertiría en el estándar de la industria. Al principio, había varios estándares en competencia, incluidos Swagger, RAML, Blueprint y WADL .
Si bien algunos de estos formatos todavía se utilizan hoy en día, las guerras de definición de API se han ganado en gran medida gracias a la especificación de OpenAPI . Este estándar surgió después de que Smartbear donara la especificación Swagger a la Iniciativa OpenAPI y obtuviera el respaldo de prácticamente todos los principales proveedores de software en el espacio API.

Después de la estandarización en torno a OpenAPI, era solo cuestión de tiempo que las herramientas maduren para admitir el estándar. Hoy en día, existen herramientas para diseñar una API visualmente, generar automáticamente un esquema OpenAPI , generar documentación basada en web , crear exploradores de API y muchas otras áreas.

Incluso hay herramientas gratuitas disponibles para realizar ingeniería inversa de un esquema OpenAPI compatible con los estándares a partir de la documentación regular basada en web. Entonces, incluso si un editor de API no proporciona un esquema de API, cualquiera puede producir el suyo.

Asimismo, las plataformas de integración están comenzando a consumir esquemas de OpenAPI y a crear servicios de integración generados por máquinas a pedido, sin pasar por alto la necesidad de un conector por completo.

Conclusión

Las iniciativas de transformación digital y la economía de las API están impulsando la adopción de API. El crecimiento exponencial resultante de las API ha hecho que sea cada vez más necesario garantizar que exista un estándar industrial para la documentación legible por máquina. El estándar resultante, OpenAPI, ha permitido a los proveedores de plataformas de integración de aplicaciones empresariales eliminar el antiguo método manual de usar conectores. En cambio, estas plataformas pueden generar servicios de integración generados por máquinas a pedido para facilitar la comunicación con las API.

Cuando una plataforma de integración elimina los conectores y admite servicios de integración generados por máquinas, empodera a los consumidores de API y se vuelven más ágiles. Tienen mayor libertad de elección para utilizar una API en función del valor que ofrece en lugar de si su plataforma de integración puede admitirla o no. Por último, pueden responder a los cambios en una API que consumen sin esperar a que el proveedor de su plataforma de integración publique una actualización que respalde el cambio.

Publicar un comentario

0 Comentarios