El café humea en la mesa, mientras el tono de llamada del Hangout se repite en mis auriculares, y repaso las preguntas que quiero hacerle a Pedro J. Molina; uno de los mayores expertos en OpenAPI de nuestro país.

Es miembro del ISA – Grupo de investigación de Ingeniería de software aplicada– de la Universidad de Sevilla, liderado por Antonio Ruiz junto a Pablo Fernández, y doctor en informática, especializado en modelado y generación de código.

Recientemente se ha integrado dentro de la Iniciativa OpenAPI, en donde participa de forma activa en la TSC (Technical Steering Committee) y el BGB (Business Governance Board). Y se ha prestado para una larga entrevista donde repasamos esta tecnología.

Una de las cosas que más me llaman la atención de Pedro, es la claridad y sencillez con que contesta las preguntas técnicas de todo nivel que le voy lanzando durante esta hora larga de conversación.

Busca la forma de explicar conceptos muy complejos, para lograr que lleguen a la mayoría de los lectores sin perder, en ningún momento, la rigurosidad de una mente científica.

¿Qué es OpenAPI?

Es un estándar para definir contratos de Api. Los cuales describen la interfaz de una serie de servicios que vamos a poder consumir por medio de una signatura. Por ejemplo, saber que vamos a tener una operación de sumar que va a recibir dos números y que estos son del tipo “entero”.

Tecnologías previas, como CORBA o SOAP, han intentado estandarizar las operaciones RPC (Llamadas a procedimientos remotos) que satisfagan la necesidad de comunicar dos máquinas que están separadas entre sí; y que requieran conocer como una tiene que invocar a la otra, especificando qué tipo de mensajes se aceptan, y qué es lo que se va a devolver.

¿Qué ventaja tiene el enfoque de OpenApi en comparación con definir un API de modo informal?

Se puede exponer un servicio de manera informal, pero la comunicación de cómo acceder al mismo también lo será.
Esta comunicación informal puede inducir o incluir equivocaciones al escribirla, describirla, o ser incompleta; siendo una documentación con muy poco valor para poder consumir el servicio, porque depende de que esté bien expresado y sea bien entendido.

Si hacemos el esfuerzo de formalizar esa definición (contrato), podemos conseguir que una máquina también la aproveche para poder conectarse al servicio y, consumiendo la especificación OpenAPI, construir un Proxy de integración. Es decir, una clase que automáticamente se conecta al servicio.

¿Pero esto no lo hacía ya los WSDL? ¿Qué falló para que sean tecnologías residuales en la actualidad?

CORBA y WSDL son tecnologías para comunicar servicios distribuidos. El paradigma SOA (Arquitectura orientada al servicio) es un estilo arquitectónico basado en la comunicación entre servicios distribuidos débilmente acoplados y altamente interoperables. SOA fue abrazado por la industria y los grandes fabricantes como Oracle, Microsoft, IBM, etc., los cuales se lanzaron a construir sus propias pilas de productos SOA que resultaron ser muy complejas y, en ocasiones, incompatibles entre sí.

Al final la complejidad del uso de la pila de productos SOA fue tal, que la industria abandonó la aplicación de los estándares más farragosos. Y con la llegada de los primeros smartphone y sus limitadas capacidades de cálculo y almacenamiento, migraron del XML al JSON (aunque el primero es mucho más extensible que el segundo) y de los Webservices (y sus sobres SOAP) a las comunicaciones REST.

¿Qué relación tiene Swagger con OpenAPI?

A finales de la década pasada empezó a crecer la economía de las API’s, la cual indica que toda aplicación que quiera escalar y triunfar en el mercado debe incluir una Interfaz de Programación de Aplicaciones potente.

En 2011, Tony Tam crea el proyecto Swagger API para automatizar la documentación y la generación del SDK (framework de desarrollo) de clientes de sus API’s. Diseñando un formato muy sencillo para describir el interfaz, en JSON o YAML, pero lo suficientemente formal como para que las máquinas lo puedan utilizar para crear Proxys (para clientes) y Skeletons (para servidores).

El éxito de Swagger fue fulgurante, convirtiéndose en un estándar “de facto”, y siendo adquirido por la empresa SmartBear que ha liberado todo el proyecto añadiéndolo a la Linux Foundation y atrayendo a los actores más importantes en la industria como Microsoft, IBM, PayPal, Adobe, Google, SAP, etc.

Y dentro de la Linux Foundation está la Iniciativa OpenAPI que es un comité dentro de la Fundación Linux que rige la evolución de la especificación.

¿Por qué está siendo tan apoyado por los fabricantes?

Si bien Swagger ya era libre, SamrtBear lo adquirió y liberó para hacerlo realmente neutral y que los diferentes fabricantes pudieran desarrollar sus ‘API Middleware’ -productos que se colocan entre tu API y el cliente final-, que te dan servicios de autenticación, autorización, seguridad, identificación, gestión de pagos, entre otros.

En una API que soporte 100 endpoints, la complejidad viene al tener que configurar nuestra herramienta para cada uno de ellos. Sin embargo, al tener una definición del contrato OpenAPI, con un sistema de drag & drop podría configurar de modo automático la herramienta de forma muy sencilla.

Los fabricantes de Middelware son los primeros interesados en que haya un estándar abierto para todos. Y, como hay negocio, se han puesto de acuerdo en dicho estándar siendo este el incentivo que ha conseguido que todos estén convergiendo hacía OpenAPI; incluso los usuarios de RAML, otro framework para definir las API, que se ha integrado en el comité de la Fundación Linux.

Pero no se circunscribe a los fabricantes, también actores tan importantes como la Banca o los gobiernos han entendido las ventajas de la estandarización en OpenAPI . Así Holanda se ha convertido en el primer estado que ha adoptado la definición para el desarrollo de sus aplicaciones.

¿Quién compone OpenAPI?

Hay una representación por cada organización que es miembro de la iniciativa. España está presente por el Grupo de investigación de Ingeniería de software aplicada (ISA) de la Universidad de Sevilla, al igual que por la startup 42 Crunch dedicada a la seguridad y gestión de amenazas a aplicaciones y datos.

El Grupo ISA hace una labor de investigación, más que orientada al negocio, trabajando en métricas de SLA donde se determina la definición de nivel de servicio. El objetivo es proponer extensiones orientadas a la medición y definición de niveles de servicio dentro de los contratos OpenAPI, aplicando la investigación realizada en la implantación industrial.

NdE. Las ramificaciones e implantaciones de estas extensiones al estándar OpenAPI aporta un valor crítico en las capacidades de aplicación de los contratos entre los interfaces de integración. En ningún otro estándar se comprende de manera específica el soporte a la medición de la calidad del servicio.

Dentro de la iniciativa OpenAPI existen tres comités diferenciados:

• El Comité Técnico, en donde se discute el estándar y se añaden extensiones. Se trabaja con reuniones semanales en donde se revisa el estado de los desarrollos.
• Comité de Gobierno, en donde se revisa el estado de la iniciativa desde un punto de vista de gestión.
• Comité de Marketing, donde se diseñan y ponen en marcha acciones de formación, difusión, visibilización, etc. Y que utiliza los fondos aportados por las organizaciones miembros para realizar los eventos o campañas.

Además, de un par de personas a tiempo completo en la Linux Foundation, dedicadas a OpenAPI.

¿Cuáles son los mayores impedimentos que te encuentras en el día a día al trabajar en los comités?

Hay que conciliar los intereses de muchos fabricantes, que cada uno quiere añadir sus propias funcionalidades, las cuales hay que discutir y acordar. Todas las cosas diseñadas por comité son un poquito más lentas que cuando swagger lo construían dos personas y añadían funcionalidad muy rápido, llevando el producto hacia donde querían.

Lo bueno es que al estar integrado en la Linux Foundation se garantiza que todo lo que se aporta está libre de patentes y que todo el mundo lo va a poder utilizar sin restricciones.

Hay veces que nos gustaría sacar las cosas más rápido, pero es necesario priorizar los temas, y los procesos van un poquito más despacio. Es importante ser cautos con las publicaciones para dar tiempo que la industria implemente estos estándares.

Por ejemplo, aún hay muchos utilizando OpenApi 2.0 mientras esperaban herramientas en desarrollo para la versión 3.0, que lanzamos hace un año.

En resumen, las dificultades de trabajar en un comité no son mayores que las de cualquier proyecto distribuido. Además, la gente que los compone tiene un gran nivel y vienen con las reuniones muy bien preparadas.

¿Puedo trabajar en la versión 3.0 apuntando a un contrato 2.0?

En el cambio de versión ha habido ruptura de compatibilidad porque había que reorganizar el estándar e implicaba una mejora muy importante. Sin embargo, próximamente vamos a publicar la versión 3.1, y en esta no va a haber ningún tipo de ruptura ya que somos especialmente cuidadosos de añadir nuevas definiciones que sean interoperables con las versiones anteriores.

¿Yo, como una persona física puedo aportar a la iniciativa OpenAPI?

Si. La manera más normal es acceder al proyecto en GitHub de la especificación y dar de alta una Issue en donde describir al detalle la petición o la aportación que quieres añadir. El comité técnico semanalmente revisa el proyecto en GitHub y, aquellas que son interesantes de desarrollar, puede solicitarte que hagas una contribución (pull request) en donde definas la implementación técnica de la propuesta o abrir una nueva tarea interna para planificar su debate y construcción.

También en el proyecto en GitHub tenemos los documentos de cada una de las reuniones del comité para poder hacer un seguimiento de alguna propuesta o del trabajo realizado, así como del roadmap de la siguiente versión que se está “cocinando”.

Por ejemplo, en la futura versión 3.1 se describen los “Overlays” que permiten extender la descripción de la API, y que podrían valer para publicar la documentación de una misma interfaz en varios idiomas; o sistemas de encriptación y firmas digitales utilizando JWE (JSON Web Encryption).

Estando previsto hacer el anuncio de esta nueva versión el próximo 24 de septiembre en la conferencia “API Strategy & Practice”.

¿Qué aportaciones habéis hecho al estándar?

Desde la Universidad de Sevilla hemos propuesto un par de herramientas para el prototipado rápido de contratos con OpenAPI. Oas-generator y Oas-tools.

A titulo personal desarrollo una librería en TypeScript (openapi-ts) y otra en .Net CORE para la creación de contratos OpenApi 3.0.x, otra que construye definiciones 3.0 para Baucis (framework de construcción de APIs REST).

Además de publicaciones en el blog de la iniciativa, como el de “Tres escenarios comunes para aprovechar la especificación OpenAPI”, y la participación semanal en el comité técnico.

Más información | Iniciativa OpenAPI de la Fundación Linux, GitHub de OpenAPI, Página de la ISA en la Universidad de Sevilla

El café humea en la mesa, mientras el tono de llamada del Hangout se repite en mis auriculares, y repaso las preguntas que quiero hacerle a Pedro J. Molina; uno de los mayores expertos en OpenAPI de nuestro país.

Es miembro del ISA – Grupo de investigación de Ingeniería de software aplicada– de la Universidad de Sevilla, liderado por Antonio Ruiz junto a Pablo Fernández, y doctor en informática, especializado en modelado y generación de código.

Recientemente se ha integrado dentro de la Iniciativa OpenAPI, en donde participa de forma activa en la TSC (Technical Steering Committee) y el BGB (Business Governance Board). Y se ha prestado para una larga entrevista donde repasamos esta tecnología.

Una de las cosas que más me llaman la atención de Pedro, es la claridad y sencillez con que contesta las preguntas técnicas de todo nivel que le voy lanzando durante esta hora larga de conversación.

Busca la forma de explicar conceptos muy complejos, para lograr que lleguen a la mayoría de los lectores sin perder, en ningún momento, la rigurosidad de una mente científica.

¿Qué es OpenAPI?

Es un estándar para definir contratos de Api. Los cuales describen la interfaz de una serie de servicios que vamos a poder consumir por medio de una signatura. Por ejemplo, saber que vamos a tener una operación de sumar que va a recibir dos números y que estos son del tipo “entero”.

Tecnologías previas, como CORBA o SOAP, han intentado estandarizar las operaciones RPC (Llamadas a procedimientos remotos) que satisfagan la necesidad de comunicar dos máquinas que están separadas entre sí; y que requieran conocer como una tiene que invocar a la otra, especificando qué tipo de mensajes se aceptan, y qué es lo que se va a devolver.

¿Qué ventaja tiene el enfoque de OpenApi en comparación con definir un API de modo informal?

Se puede exponer un servicio de manera informal, pero la comunicación de cómo acceder al mismo también lo será.
Esta comunicación informal puede inducir o incluir equivocaciones al escribirla, describirla, o ser incompleta; siendo una documentación con muy poco valor para poder consumir el servicio, porque depende de que esté bien expresado y sea bien entendido.

Si hacemos el esfuerzo de formalizar esa definición (contrato), podemos conseguir que una máquina también la aproveche para poder conectarse al servicio y, consumiendo la especificación OpenAPI, construir un Proxy de integración. Es decir, una clase que automáticamente se conecta al servicio.

¿Pero esto no lo hacía ya los WSDL? ¿Qué falló para que sean tecnologías residuales en la actualidad?

CORBA y WSDL son tecnologías para comunicar servicios distribuidos. El paradigma SOA (Arquitectura orientada al servicio) es un estilo arquitectónico basado en la comunicación entre servicios distribuidos débilmente acoplados y altamente interoperables. SOA fue abrazado por la industria y los grandes fabricantes como Oracle, Microsoft, IBM, etc., los cuales se lanzaron a construir sus propias pilas de productos SOA que resultaron ser muy complejas y, en ocasiones, incompatibles entre sí.

Al final la complejidad del uso de la pila de productos SOA fue tal, que la industria abandonó la aplicación de los estándares más farragosos. Y con la llegada de los primeros smartphone y sus limitadas capacidades de cálculo y almacenamiento, migraron del XML al JSON (aunque el primero es mucho más extensible que el segundo) y de los Webservices (y sus sobres SOAP) a las comunicaciones REST.

¿Qué relación tiene Swagger con OpenAPI?

A finales de la década pasada empezó a crecer la economía de las API’s, la cual indica que toda aplicación que quiera escalar y triunfar en el mercado debe incluir una Interfaz de Programación de Aplicaciones potente.

En 2011, Tony Tam crea el proyecto Swagger API para automatizar la documentación y la generación del SDK (framework de desarrollo) de clientes de sus API’s. Diseñando un formato muy sencillo para describir el interfaz, en JSON o YAML, pero lo suficientemente formal como para que las máquinas lo puedan utilizar para crear Proxys (para clientes) y Skeletons (para servidores).

El éxito de Swagger fue fulgurante, convirtiéndose en un estándar “de facto”, y siendo adquirido por la empresa SmartBear que ha liberado todo el proyecto añadiéndolo a la Linux Foundation y atrayendo a los actores más importantes en la industria como Microsoft, IBM, PayPal, Adobe, Google, SAP, etc.

Y dentro de la Linux Foundation está la Iniciativa OpenAPI que es un comité dentro de la Fundación Linux que rige la evolución de la especificación.

¿Por qué está siendo tan apoyado por los fabricantes?

Si bien Swagger ya era libre, SamrtBear lo adquirió y liberó para hacerlo realmente neutral y que los diferentes fabricantes pudieran desarrollar sus ‘API Middleware’ -productos que se colocan entre tu API y el cliente final-, que te dan servicios de autenticación, autorización, seguridad, identificación, gestión de pagos, entre otros.

En una API que soporte 100 endpoints, la complejidad viene al tener que configurar nuestra herramienta para cada uno de ellos. Sin embargo, al tener una definición del contrato OpenAPI, con un sistema de drag & drop podría configurar de modo automático la herramienta de forma muy sencilla.

Los fabricantes de Middelware son los primeros interesados en que haya un estándar abierto para todos. Y, como hay negocio, se han puesto de acuerdo en dicho estándar siendo este el incentivo que ha conseguido que todos estén convergiendo hacía OpenAPI; incluso los usuarios de RAML, otro framework para definir las API, que se ha integrado en el comité de la Fundación Linux.

Pero no se circunscribe a los fabricantes, también actores tan importantes como la Banca o los gobiernos han entendido las ventajas de la estandarización en OpenAPI . Así Holanda se ha convertido en el primer estado que ha adoptado la definición para el desarrollo de sus aplicaciones.

¿Quién compone OpenAPI?

Hay una representación por cada organización que es miembro de la iniciativa. España está presente por el Grupo de investigación de Ingeniería de software aplicada (ISA) de la Universidad de Sevilla, al igual que por la startup 42 Crunch dedicada a la seguridad y gestión de amenazas a aplicaciones y datos.

El Grupo ISA hace una labor de investigación, más que orientada al negocio, trabajando en métricas de SLA donde se determina la definición de nivel de servicio. El objetivo es proponer extensiones orientadas a la medición y definición de niveles de servicio dentro de los contratos OpenAPI, aplicando la investigación realizada en la implantación industrial.

NdE. Las ramificaciones e implantaciones de estas extensiones al estándar OpenAPI aporta un valor crítico en las capacidades de aplicación de los contratos entre los interfaces de integración. En ningún otro estándar se comprende de manera específica el soporte a la medición de la calidad del servicio.

Dentro de la iniciativa OpenAPI existen tres comités diferenciados:

• El Comité Técnico, en donde se discute el estándar y se añaden extensiones. Se trabaja con reuniones semanales en donde se revisa el estado de los desarrollos.
• Comité de Gobierno, en donde se revisa el estado de la iniciativa desde un punto de vista de gestión.
• Comité de Marketing, donde se diseñan y ponen en marcha acciones de formación, difusión, visibilización, etc. Y que utiliza los fondos aportados por las organizaciones miembros para realizar los eventos o campañas.

Además, de un par de personas a tiempo completo en la Linux Foundation, dedicadas a OpenAPI.

¿Cuáles son los mayores impedimentos que te encuentras en el día a día al trabajar en los comités?

Hay que conciliar los intereses de muchos fabricantes, que cada uno quiere añadir sus propias funcionalidades, las cuales hay que discutir y acordar. Todas las cosas diseñadas por comité son un poquito más lentas que cuando swagger lo construían dos personas y añadían funcionalidad muy rápido, llevando el producto hacia donde querían.

Lo bueno es que al estar integrado en la Linux Foundation se garantiza que todo lo que se aporta está libre de patentes y que todo el mundo lo va a poder utilizar sin restricciones.

Hay veces que nos gustaría sacar las cosas más rápido, pero es necesario priorizar los temas, y los procesos van un poquito más despacio. Es importante ser cautos con las publicaciones para dar tiempo que la industria implemente estos estándares.

Por ejemplo, aún hay muchos utilizando OpenApi 2.0 mientras esperaban herramientas en desarrollo para la versión 3.0, que lanzamos hace un año.

En resumen, las dificultades de trabajar en un comité no son mayores que las de cualquier proyecto distribuido. Además, la gente que los compone tiene un gran nivel y vienen con las reuniones muy bien preparadas.

¿Puedo trabajar en la versión 3.0 apuntando a un contrato 2.0?

En el cambio de versión ha habido ruptura de compatibilidad porque había que reorganizar el estándar e implicaba una mejora muy importante. Sin embargo, próximamente vamos a publicar la versión 3.1, y en esta no va a haber ningún tipo de ruptura ya que somos especialmente cuidadosos de añadir nuevas definiciones que sean interoperables con las versiones anteriores.

¿Yo, como una persona física puedo aportar a la iniciativa OpenAPI?

Si. La manera más normal es acceder al proyecto en GitHub de la especificación y dar de alta una Issue en donde describir al detalle la petición o la aportación que quieres añadir. El comité técnico semanalmente revisa el proyecto en GitHub y, aquellas que son interesantes de desarrollar, puede solicitarte que hagas una contribución (pull request) en donde definas la implementación técnica de la propuesta o abrir una nueva tarea interna para planificar su debate y construcción.

También en el proyecto en GitHub tenemos los documentos de cada una de las reuniones del comité para poder hacer un seguimiento de alguna propuesta o del trabajo realizado, así como del roadmap de la siguiente versión que se está “cocinando”.

Por ejemplo, en la futura versión 3.1 se describen los “Overlays” que permiten extender la descripción de la API, y que podrían valer para publicar la documentación de una misma interfaz en varios idiomas; o sistemas de encriptación y firmas digitales utilizando JWE (JSON Web Encryption).

Estando previsto hacer el anuncio de esta nueva versión el próximo 24 de septiembre en la conferencia “API Strategy & Practice”.

¿Qué aportaciones habéis hecho al estándar?

Desde la Universidad de Sevilla hemos propuesto un par de herramientas para el prototipado rápido de contratos con OpenAPI. Oas-generator y Oas-tools.

A titulo personal desarrollo una librería en TypeScript (openapi-ts) y otra en .Net CORE para la creación de contratos OpenApi 3.0.x, otra que construye definiciones 3.0 para Baucis (framework de construcción de APIs REST).

Además de publicaciones en el blog de la iniciativa, como el de “Tres escenarios comunes para aprovechar la especificación OpenAPI”, y la participación semanal en el comité técnico.

Más información | Iniciativa OpenAPI de la Fundación Linux, GitHub de OpenAPI, Página de la ISA en la Universidad de Sevilla

El café humea en la mesa, mientras el tono de llamada del Hangout se repite en mis auriculares, y repaso las preguntas que quiero hacerle a Pedro J. Molina; uno de los mayores expertos en OpenAPI de nuestro país.

Es miembro del ISA – Grupo de investigación de Ingeniería de software aplicada– de la Universidad de Sevilla, liderado por Antonio Ruiz junto a Pablo Fernández, y doctor en informática, especializado en modelado y generación de código.

Recientemente se ha integrado dentro de la Iniciativa OpenAPI, en donde participa de forma activa en la TSC (Technical Steering Committee) y el BGB (Business Governance Board). Y se ha prestado para una larga entrevista donde repasamos esta tecnología.

Una de las cosas que más me llaman la atención de Pedro, es la claridad y sencillez con que contesta las preguntas técnicas de todo nivel que le voy lanzando durante esta hora larga de conversación.

Busca la forma de explicar conceptos muy complejos, para lograr que lleguen a la mayoría de los lectores sin perder, en ningún momento, la rigurosidad de una mente científica.

¿Qué es OpenAPI?

Es un estándar para definir contratos de Api. Los cuales describen la interfaz de una serie de servicios que vamos a poder consumir por medio de una signatura. Por ejemplo, saber que vamos a tener una operación de sumar que va a recibir dos números y que estos son del tipo “entero”.

Tecnologías previas, como CORBA o SOAP, han intentado estandarizar las operaciones RPC (Llamadas a procedimientos remotos) que satisfagan la necesidad de comunicar dos máquinas que están separadas entre sí; y que requieran conocer como una tiene que invocar a la otra, especificando qué tipo de mensajes se aceptan, y qué es lo que se va a devolver.

¿Qué ventaja tiene el enfoque de OpenApi en comparación con definir un API de modo informal?

Se puede exponer un servicio de manera informal, pero la comunicación de cómo acceder al mismo también lo será.
Esta comunicación informal puede inducir o incluir equivocaciones al escribirla, describirla, o ser incompleta; siendo una documentación con muy poco valor para poder consumir el servicio, porque depende de que esté bien expresado y sea bien entendido.

Si hacemos el esfuerzo de formalizar esa definición (contrato), podemos conseguir que una máquina también la aproveche para poder conectarse al servicio y, consumiendo la especificación OpenAPI, construir un Proxy de integración. Es decir, una clase que automáticamente se conecta al servicio.

¿Pero esto no lo hacía ya los WSDL? ¿Qué falló para que sean tecnologías residuales en la actualidad?

CORBA y WSDL son tecnologías para comunicar servicios distribuidos. El paradigma SOA (Arquitectura orientada al servicio) es un estilo arquitectónico basado en la comunicación entre servicios distribuidos débilmente acoplados y altamente interoperables. SOA fue abrazado por la industria y los grandes fabricantes como Oracle, Microsoft, IBM, etc., los cuales se lanzaron a construir sus propias pilas de productos SOA que resultaron ser muy complejas y, en ocasiones, incompatibles entre sí.

Al final la complejidad del uso de la pila de productos SOA fue tal, que la industria abandonó la aplicación de los estándares más farragosos. Y con la llegada de los primeros smartphone y sus limitadas capacidades de cálculo y almacenamiento, migraron del XML al JSON (aunque el primero es mucho más extensible que el segundo) y de los Webservices (y sus sobres SOAP) a las comunicaciones REST.

¿Qué relación tiene Swagger con OpenAPI?

A finales de la década pasada empezó a crecer la economía de las API’s, la cual indica que toda aplicación que quiera escalar y triunfar en el mercado debe incluir una Interfaz de Programación de Aplicaciones potente.

En 2011, Tony Tam crea el proyecto Swagger API para automatizar la documentación y la generación del SDK (framework de desarrollo) de clientes de sus API’s. Diseñando un formato muy sencillo para describir el interfaz, en JSON o YAML, pero lo suficientemente formal como para que las máquinas lo puedan utilizar para crear Proxys (para clientes) y Skeletons (para servidores).

El éxito de Swagger fue fulgurante, convirtiéndose en un estándar “de facto”, y siendo adquirido por la empresa SmartBear que ha liberado todo el proyecto añadiéndolo a la Linux Foundation y atrayendo a los actores más importantes en la industria como Microsoft, IBM, PayPal, Adobe, Google, SAP, etc.

Y dentro de la Linux Foundation está la Iniciativa OpenAPI que es un comité dentro de la Fundación Linux que rige la evolución de la especificación.

¿Por qué está siendo tan apoyado por los fabricantes?

Si bien Swagger ya era libre, SamrtBear lo adquirió y liberó para hacerlo realmente neutral y que los diferentes fabricantes pudieran desarrollar sus ‘API Middleware’ -productos que se colocan entre tu API y el cliente final-, que te dan servicios de autenticación, autorización, seguridad, identificación, gestión de pagos, entre otros.

En una API que soporte 100 endpoints, la complejidad viene al tener que configurar nuestra herramienta para cada uno de ellos. Sin embargo, al tener una definición del contrato OpenAPI, con un sistema de drag & drop podría configurar de modo automático la herramienta de forma muy sencilla.

Los fabricantes de Middelware son los primeros interesados en que haya un estándar abierto para todos. Y, como hay negocio, se han puesto de acuerdo en dicho estándar siendo este el incentivo que ha conseguido que todos estén convergiendo hacía OpenAPI; incluso los usuarios de RAML, otro framework para definir las API, que se ha integrado en el comité de la Fundación Linux.

Pero no se circunscribe a los fabricantes, también actores tan importantes como la Banca o los gobiernos han entendido las ventajas de la estandarización en OpenAPI . Así Holanda se ha convertido en el primer estado que ha adoptado la definición para el desarrollo de sus aplicaciones.

¿Quién compone OpenAPI?

Hay una representación por cada organización que es miembro de la iniciativa. España está presente por el Grupo de investigación de Ingeniería de software aplicada (ISA) de la Universidad de Sevilla, al igual que por la startup 42 Crunch dedicada a la seguridad y gestión de amenazas a aplicaciones y datos.

El Grupo ISA hace una labor de investigación, más que orientada al negocio, trabajando en métricas de SLA donde se determina la definición de nivel de servicio. El objetivo es proponer extensiones orientadas a la medición y definición de niveles de servicio dentro de los contratos OpenAPI, aplicando la investigación realizada en la implantación industrial.

NdE. Las ramificaciones e implantaciones de estas extensiones al estándar OpenAPI aporta un valor crítico en las capacidades de aplicación de los contratos entre los interfaces de integración. En ningún otro estándar se comprende de manera específica el soporte a la medición de la calidad del servicio.

Dentro de la iniciativa OpenAPI existen tres comités diferenciados:

• El Comité Técnico, en donde se discute el estándar y se añaden extensiones. Se trabaja con reuniones semanales en donde se revisa el estado de los desarrollos.
• Comité de Gobierno, en donde se revisa el estado de la iniciativa desde un punto de vista de gestión.
• Comité de Marketing, donde se diseñan y ponen en marcha acciones de formación, difusión, visibilización, etc. Y que utiliza los fondos aportados por las organizaciones miembros para realizar los eventos o campañas.

Además, de un par de personas a tiempo completo en la Linux Foundation, dedicadas a OpenAPI.

¿Cuáles son los mayores impedimentos que te encuentras en el día a día al trabajar en los comités?

Hay que conciliar los intereses de muchos fabricantes, que cada uno quiere añadir sus propias funcionalidades, las cuales hay que discutir y acordar. Todas las cosas diseñadas por comité son un poquito más lentas que cuando swagger lo construían dos personas y añadían funcionalidad muy rápido, llevando el producto hacia donde querían.

Lo bueno es que al estar integrado en la Linux Foundation se garantiza que todo lo que se aporta está libre de patentes y que todo el mundo lo va a poder utilizar sin restricciones.

Hay veces que nos gustaría sacar las cosas más rápido, pero es necesario priorizar los temas, y los procesos van un poquito más despacio. Es importante ser cautos con las publicaciones para dar tiempo que la industria implemente estos estándares.

Por ejemplo, aún hay muchos utilizando OpenApi 2.0 mientras esperaban herramientas en desarrollo para la versión 3.0, que lanzamos hace un año.

En resumen, las dificultades de trabajar en un comité no son mayores que las de cualquier proyecto distribuido. Además, la gente que los compone tiene un gran nivel y vienen con las reuniones muy bien preparadas.

¿Puedo trabajar en la versión 3.0 apuntando a un contrato 2.0?

En el cambio de versión ha habido ruptura de compatibilidad porque había que reorganizar el estándar e implicaba una mejora muy importante. Sin embargo, próximamente vamos a publicar la versión 3.1, y en esta no va a haber ningún tipo de ruptura ya que somos especialmente cuidadosos de añadir nuevas definiciones que sean interoperables con las versiones anteriores.

¿Yo, como una persona física puedo aportar a la iniciativa OpenAPI?

Si. La manera más normal es acceder al proyecto en GitHub de la especificación y dar de alta una Issue en donde describir al detalle la petición o la aportación que quieres añadir. El comité técnico semanalmente revisa el proyecto en GitHub y, aquellas que son interesantes de desarrollar, puede solicitarte que hagas una contribución (pull request) en donde definas la implementación técnica de la propuesta o abrir una nueva tarea interna para planificar su debate y construcción.

También en el proyecto en GitHub tenemos los documentos de cada una de las reuniones del comité para poder hacer un seguimiento de alguna propuesta o del trabajo realizado, así como del roadmap de la siguiente versión que se está “cocinando”.

Por ejemplo, en la futura versión 3.1 se describen los “Overlays” que permiten extender la descripción de la API, y que podrían valer para publicar la documentación de una misma interfaz en varios idiomas; o sistemas de encriptación y firmas digitales utilizando JWE (JSON Web Encryption).

Estando previsto hacer el anuncio de esta nueva versión el próximo 24 de septiembre en la conferencia “API Strategy & Practice”.

¿Qué aportaciones habéis hecho al estándar?

Desde la Universidad de Sevilla hemos propuesto un par de herramientas para el prototipado rápido de contratos con OpenAPI. Oas-generator y Oas-tools.

A titulo personal desarrollo una librería en TypeScript (openapi-ts) y otra en .Net CORE para la creación de contratos OpenApi 3.0.x, otra que construye definiciones 3.0 para Baucis (framework de construcción de APIs REST).

Además de publicaciones en el blog de la iniciativa, como el de “Tres escenarios comunes para aprovechar la especificación OpenAPI”, y la participación semanal en el comité técnico.

Más información | Iniciativa OpenAPI de la Fundación Linux, GitHub de OpenAPI, Página de la ISA en la Universidad de Sevilla

El café humea en la mesa, mientras el tono de llamada del Hangout se repite en mis auriculares, y repaso las preguntas que quiero hacerle a Pedro J. Molina; uno de los mayores expertos en OpenAPI de nuestro país.

Es miembro del ISA – Grupo de investigación de Ingeniería de software aplicada– de la Universidad de Sevilla, liderado por Antonio Ruiz junto a Pablo Fernández, y doctor en informática, especializado en modelado y generación de código.

Recientemente se ha integrado dentro de la Iniciativa OpenAPI, en donde participa de forma activa en la TSC (Technical Steering Committee) y el BGB (Business Governance Board). Y se ha prestado para una larga entrevista donde repasamos esta tecnología.

Una de las cosas que más me llaman la atención de Pedro, es la claridad y sencillez con que contesta las preguntas técnicas de todo nivel que le voy lanzando durante esta hora larga de conversación.

Busca la forma de explicar conceptos muy complejos, para lograr que lleguen a la mayoría de los lectores sin perder, en ningún momento, la rigurosidad de una mente científica.

¿Qué es OpenAPI?

Es un estándar para definir contratos de Api. Los cuales describen la interfaz de una serie de servicios que vamos a poder consumir por medio de una signatura. Por ejemplo, saber que vamos a tener una operación de sumar que va a recibir dos números y que estos son del tipo “entero”.

Tecnologías previas, como CORBA o SOAP, han intentado estandarizar las operaciones RPC (Llamadas a procedimientos remotos) que satisfagan la necesidad de comunicar dos máquinas que están separadas entre sí; y que requieran conocer como una tiene que invocar a la otra, especificando qué tipo de mensajes se aceptan, y qué es lo que se va a devolver.

¿Qué ventaja tiene el enfoque de OpenApi en comparación con definir un API de modo informal?

Se puede exponer un servicio de manera informal, pero la comunicación de cómo acceder al mismo también lo será.
Esta comunicación informal puede inducir o incluir equivocaciones al escribirla, describirla, o ser incompleta; siendo una documentación con muy poco valor para poder consumir el servicio, porque depende de que esté bien expresado y sea bien entendido.

Si hacemos el esfuerzo de formalizar esa definición (contrato), podemos conseguir que una máquina también la aproveche para poder conectarse al servicio y, consumiendo la especificación OpenAPI, construir un Proxy de integración. Es decir, una clase que automáticamente se conecta al servicio.

¿Pero esto no lo hacía ya los WSDL? ¿Qué falló para que sean tecnologías residuales en la actualidad?

CORBA y WSDL son tecnologías para comunicar servicios distribuidos. El paradigma SOA (Arquitectura orientada al servicio) es un estilo arquitectónico basado en la comunicación entre servicios distribuidos débilmente acoplados y altamente interoperables. SOA fue abrazado por la industria y los grandes fabricantes como Oracle, Microsoft, IBM, etc., los cuales se lanzaron a construir sus propias pilas de productos SOA que resultaron ser muy complejas y, en ocasiones, incompatibles entre sí.

Al final la complejidad del uso de la pila de productos SOA fue tal, que la industria abandonó la aplicación de los estándares más farragosos. Y con la llegada de los primeros smartphone y sus limitadas capacidades de cálculo y almacenamiento, migraron del XML al JSON (aunque el primero es mucho más extensible que el segundo) y de los Webservices (y sus sobres SOAP) a las comunicaciones REST.

¿Qué relación tiene Swagger con OpenAPI?

A finales de la década pasada empezó a crecer la economía de las API’s, la cual indica que toda aplicación que quiera escalar y triunfar en el mercado debe incluir una Interfaz de Programación de Aplicaciones potente.

En 2011, Tony Tam crea el proyecto Swagger API para automatizar la documentación y la generación del SDK (framework de desarrollo) de clientes de sus API’s. Diseñando un formato muy sencillo para describir el interfaz, en JSON o YAML, pero lo suficientemente formal como para que las máquinas lo puedan utilizar para crear Proxys (para clientes) y Skeletons (para servidores).

El éxito de Swagger fue fulgurante, convirtiéndose en un estándar “de facto”, y siendo adquirido por la empresa SmartBear que ha liberado todo el proyecto añadiéndolo a la Linux Foundation y atrayendo a los actores más importantes en la industria como Microsoft, IBM, PayPal, Adobe, Google, SAP, etc.

Y dentro de la Linux Foundation está la Iniciativa OpenAPI que es un comité dentro de la Fundación Linux que rige la evolución de la especificación.

¿Por qué está siendo tan apoyado por los fabricantes?

Si bien Swagger ya era libre, SamrtBear lo adquirió y liberó para hacerlo realmente neutral y que los diferentes fabricantes pudieran desarrollar sus ‘API Middleware’ -productos que se colocan entre tu API y el cliente final-, que te dan servicios de autenticación, autorización, seguridad, identificación, gestión de pagos, entre otros.

En una API que soporte 100 endpoints, la complejidad viene al tener que configurar nuestra herramienta para cada uno de ellos. Sin embargo, al tener una definición del contrato OpenAPI, con un sistema de drag & drop podría configurar de modo automático la herramienta de forma muy sencilla.

Los fabricantes de Middelware son los primeros interesados en que haya un estándar abierto para todos. Y, como hay negocio, se han puesto de acuerdo en dicho estándar siendo este el incentivo que ha conseguido que todos estén convergiendo hacía OpenAPI; incluso los usuarios de RAML, otro framework para definir las API, que se ha integrado en el comité de la Fundación Linux.

Pero no se circunscribe a los fabricantes, también actores tan importantes como la Banca o los gobiernos han entendido las ventajas de la estandarización en OpenAPI . Así Holanda se ha convertido en el primer estado que ha adoptado la definición para el desarrollo de sus aplicaciones.

¿Quién compone OpenAPI?

Hay una representación por cada organización que es miembro de la iniciativa. España está presente por el Grupo de investigación de Ingeniería de software aplicada (ISA) de la Universidad de Sevilla, al igual que por la startup 42 Crunch dedicada a la seguridad y gestión de amenazas a aplicaciones y datos.

El Grupo ISA hace una labor de investigación, más que orientada al negocio, trabajando en métricas de SLA donde se determina la definición de nivel de servicio. El objetivo es proponer extensiones orientadas a la medición y definición de niveles de servicio dentro de los contratos OpenAPI, aplicando la investigación realizada en la implantación industrial.

NdE. Las ramificaciones e implantaciones de estas extensiones al estándar OpenAPI aporta un valor crítico en las capacidades de aplicación de los contratos entre los interfaces de integración. En ningún otro estándar se comprende de manera específica el soporte a la medición de la calidad del servicio.

Dentro de la iniciativa OpenAPI existen tres comités diferenciados:

• El Comité Técnico, en donde se discute el estándar y se añaden extensiones. Se trabaja con reuniones semanales en donde se revisa el estado de los desarrollos.
• Comité de Gobierno, en donde se revisa el estado de la iniciativa desde un punto de vista de gestión.
• Comité de Marketing, donde se diseñan y ponen en marcha acciones de formación, difusión, visibilización, etc. Y que utiliza los fondos aportados por las organizaciones miembros para realizar los eventos o campañas.

Además, de un par de personas a tiempo completo en la Linux Foundation, dedicadas a OpenAPI.

¿Cuáles son los mayores impedimentos que te encuentras en el día a día al trabajar en los comités?

Hay que conciliar los intereses de muchos fabricantes, que cada uno quiere añadir sus propias funcionalidades, las cuales hay que discutir y acordar. Todas las cosas diseñadas por comité son un poquito más lentas que cuando swagger lo construían dos personas y añadían funcionalidad muy rápido, llevando el producto hacia donde querían.

Lo bueno es que al estar integrado en la Linux Foundation se garantiza que todo lo que se aporta está libre de patentes y que todo el mundo lo va a poder utilizar sin restricciones.

Hay veces que nos gustaría sacar las cosas más rápido, pero es necesario priorizar los temas, y los procesos van un poquito más despacio. Es importante ser cautos con las publicaciones para dar tiempo que la industria implemente estos estándares.

Por ejemplo, aún hay muchos utilizando OpenApi 2.0 mientras esperaban herramientas en desarrollo para la versión 3.0, que lanzamos hace un año.

En resumen, las dificultades de trabajar en un comité no son mayores que las de cualquier proyecto distribuido. Además, la gente que los compone tiene un gran nivel y vienen con las reuniones muy bien preparadas.

¿Puedo trabajar en la versión 3.0 apuntando a un contrato 2.0?

En el cambio de versión ha habido ruptura de compatibilidad porque había que reorganizar el estándar e implicaba una mejora muy importante. Sin embargo, próximamente vamos a publicar la versión 3.1, y en esta no va a haber ningún tipo de ruptura ya que somos especialmente cuidadosos de añadir nuevas definiciones que sean interoperables con las versiones anteriores.

¿Yo, como una persona física puedo aportar a la iniciativa OpenAPI?

Si. La manera más normal es acceder al proyecto en GitHub de la especificación y dar de alta una Issue en donde describir al detalle la petición o la aportación que quieres añadir. El comité técnico semanalmente revisa el proyecto en GitHub y, aquellas que son interesantes de desarrollar, puede solicitarte que hagas una contribución (pull request) en donde definas la implementación técnica de la propuesta o abrir una nueva tarea interna para planificar su debate y construcción.

También en el proyecto en GitHub tenemos los documentos de cada una de las reuniones del comité para poder hacer un seguimiento de alguna propuesta o del trabajo realizado, así como del roadmap de la siguiente versión que se está “cocinando”.

Por ejemplo, en la futura versión 3.1 se describen los “Overlays” que permiten extender la descripción de la API, y que podrían valer para publicar la documentación de una misma interfaz en varios idiomas; o sistemas de encriptación y firmas digitales utilizando JWE (JSON Web Encryption).

Estando previsto hacer el anuncio de esta nueva versión el próximo 24 de septiembre en la conferencia “API Strategy & Practice”.

¿Qué aportaciones habéis hecho al estándar?

Desde la Universidad de Sevilla hemos propuesto un par de herramientas para el prototipado rápido de contratos con OpenAPI. Oas-generator y Oas-tools.

A titulo personal desarrollo una librería en TypeScript (openapi-ts) y otra en .Net CORE para la creación de contratos OpenApi 3.0.x, otra que construye definiciones 3.0 para Baucis (framework de construcción de APIs REST).

Además de publicaciones en el blog de la iniciativa, como el de “Tres escenarios comunes para aprovechar la especificación OpenAPI”, y la participación semanal en el comité técnico.

Más información | Iniciativa OpenAPI de la Fundación Linux, GitHub de OpenAPI, Página de la ISA en la Universidad de Sevilla

El café humea en la mesa, mientras el tono de llamada del Hangout se repite en mis auriculares, y repaso las preguntas que quiero hacerle a Pedro J. Molina; uno de los mayores expertos en OpenAPI de nuestro país.

Es miembro del ISA – Grupo de investigación de Ingeniería de software aplicada– de la Universidad de Sevilla, liderado por Antonio Ruiz junto a Pablo Fernández, y doctor en informática, especializado en modelado y generación de código.

Recientemente se ha integrado dentro de la Iniciativa OpenAPI, en donde participa de forma activa en la TSC (Technical Steering Committee) y el BGB (Business Governance Board). Y se ha prestado para una larga entrevista donde repasamos esta tecnología.

Una de las cosas que más me llaman la atención de Pedro, es la claridad y sencillez con que contesta las preguntas técnicas de todo nivel que le voy lanzando durante esta hora larga de conversación.

Busca la forma de explicar conceptos muy complejos, para lograr que lleguen a la mayoría de los lectores sin perder, en ningún momento, la rigurosidad de una mente científica.

¿Qué es OpenAPI?

Es un estándar para definir contratos de Api. Los cuales describen la interfaz de una serie de servicios que vamos a poder consumir por medio de una signatura. Por ejemplo, saber que vamos a tener una operación de sumar que va a recibir dos números y que estos son del tipo “entero”.

Tecnologías previas, como CORBA o SOAP, han intentado estandarizar las operaciones RPC (Llamadas a procedimientos remotos) que satisfagan la necesidad de comunicar dos máquinas que están separadas entre sí; y que requieran conocer como una tiene que invocar a la otra, especificando qué tipo de mensajes se aceptan, y qué es lo que se va a devolver.

¿Qué ventaja tiene el enfoque de OpenApi en comparación con definir un API de modo informal?

Se puede exponer un servicio de manera informal, pero la comunicación de cómo acceder al mismo también lo será.
Esta comunicación informal puede inducir o incluir equivocaciones al escribirla, describirla, o ser incompleta; siendo una documentación con muy poco valor para poder consumir el servicio, porque depende de que esté bien expresado y sea bien entendido.

Si hacemos el esfuerzo de formalizar esa definición (contrato), podemos conseguir que una máquina también la aproveche para poder conectarse al servicio y, consumiendo la especificación OpenAPI, construir un Proxy de integración. Es decir, una clase que automáticamente se conecta al servicio.

¿Pero esto no lo hacía ya los WSDL? ¿Qué falló para que sean tecnologías residuales en la actualidad?

CORBA y WSDL son tecnologías para comunicar servicios distribuidos. El paradigma SOA (Arquitectura orientada al servicio) es un estilo arquitectónico basado en la comunicación entre servicios distribuidos débilmente acoplados y altamente interoperables. SOA fue abrazado por la industria y los grandes fabricantes como Oracle, Microsoft, IBM, etc., los cuales se lanzaron a construir sus propias pilas de productos SOA que resultaron ser muy complejas y, en ocasiones, incompatibles entre sí.

Al final la complejidad del uso de la pila de productos SOA fue tal, que la industria abandonó la aplicación de los estándares más farragosos. Y con la llegada de los primeros smartphone y sus limitadas capacidades de cálculo y almacenamiento, migraron del XML al JSON (aunque el primero es mucho más extensible que el segundo) y de los Webservices (y sus sobres SOAP) a las comunicaciones REST.

¿Qué relación tiene Swagger con OpenAPI?

A finales de la década pasada empezó a crecer la economía de las API’s, la cual indica que toda aplicación que quiera escalar y triunfar en el mercado debe incluir una Interfaz de Programación de Aplicaciones potente.

En 2011, Tony Tam crea el proyecto Swagger API para automatizar la documentación y la generación del SDK (framework de desarrollo) de clientes de sus API’s. Diseñando un formato muy sencillo para describir el interfaz, en JSON o YAML, pero lo suficientemente formal como para que las máquinas lo puedan utilizar para crear Proxys (para clientes) y Skeletons (para servidores).

El éxito de Swagger fue fulgurante, convirtiéndose en un estándar “de facto”, y siendo adquirido por la empresa SmartBear que ha liberado todo el proyecto añadiéndolo a la Linux Foundation y atrayendo a los actores más importantes en la industria como Microsoft, IBM, PayPal, Adobe, Google, SAP, etc.

Y dentro de la Linux Foundation está la Iniciativa OpenAPI que es un comité dentro de la Fundación Linux que rige la evolución de la especificación.

¿Por qué está siendo tan apoyado por los fabricantes?

Si bien Swagger ya era libre, SamrtBear lo adquirió y liberó para hacerlo realmente neutral y que los diferentes fabricantes pudieran desarrollar sus ‘API Middleware’ -productos que se colocan entre tu API y el cliente final-, que te dan servicios de autenticación, autorización, seguridad, identificación, gestión de pagos, entre otros.

En una API que soporte 100 endpoints, la complejidad viene al tener que configurar nuestra herramienta para cada uno de ellos. Sin embargo, al tener una definición del contrato OpenAPI, con un sistema de drag & drop podría configurar de modo automático la herramienta de forma muy sencilla.

Los fabricantes de Middelware son los primeros interesados en que haya un estándar abierto para todos. Y, como hay negocio, se han puesto de acuerdo en dicho estándar siendo este el incentivo que ha conseguido que todos estén convergiendo hacía OpenAPI; incluso los usuarios de RAML, otro framework para definir las API, que se ha integrado en el comité de la Fundación Linux.

Pero no se circunscribe a los fabricantes, también actores tan importantes como la Banca o los gobiernos han entendido las ventajas de la estandarización en OpenAPI . Así Holanda se ha convertido en el primer estado que ha adoptado la definición para el desarrollo de sus aplicaciones.

¿Quién compone OpenAPI?

Hay una representación por cada organización que es miembro de la iniciativa. España está presente por el Grupo de investigación de Ingeniería de software aplicada (ISA) de la Universidad de Sevilla, al igual que por la startup 42 Crunch dedicada a la seguridad y gestión de amenazas a aplicaciones y datos.

El Grupo ISA hace una labor de investigación, más que orientada al negocio, trabajando en métricas de SLA donde se determina la definición de nivel de servicio. El objetivo es proponer extensiones orientadas a la medición y definición de niveles de servicio dentro de los contratos OpenAPI, aplicando la investigación realizada en la implantación industrial.

NdE. Las ramificaciones e implantaciones de estas extensiones al estándar OpenAPI aporta un valor crítico en las capacidades de aplicación de los contratos entre los interfaces de integración. En ningún otro estándar se comprende de manera específica el soporte a la medición de la calidad del servicio.

Dentro de la iniciativa OpenAPI existen tres comités diferenciados:

• El Comité Técnico, en donde se discute el estándar y se añaden extensiones. Se trabaja con reuniones semanales en donde se revisa el estado de los desarrollos.
• Comité de Gobierno, en donde se revisa el estado de la iniciativa desde un punto de vista de gestión.
• Comité de Marketing, donde se diseñan y ponen en marcha acciones de formación, difusión, visibilización, etc. Y que utiliza los fondos aportados por las organizaciones miembros para realizar los eventos o campañas.

Además, de un par de personas a tiempo completo en la Linux Foundation, dedicadas a OpenAPI.

¿Cuáles son los mayores impedimentos que te encuentras en el día a día al trabajar en los comités?

Hay que conciliar los intereses de muchos fabricantes, que cada uno quiere añadir sus propias funcionalidades, las cuales hay que discutir y acordar. Todas las cosas diseñadas por comité son un poquito más lentas que cuando swagger lo construían dos personas y añadían funcionalidad muy rápido, llevando el producto hacia donde querían.

Lo bueno es que al estar integrado en la Linux Foundation se garantiza que todo lo que se aporta está libre de patentes y que todo el mundo lo va a poder utilizar sin restricciones.

Hay veces que nos gustaría sacar las cosas más rápido, pero es necesario priorizar los temas, y los procesos van un poquito más despacio. Es importante ser cautos con las publicaciones para dar tiempo que la industria implemente estos estándares.

Por ejemplo, aún hay muchos utilizando OpenApi 2.0 mientras esperaban herramientas en desarrollo para la versión 3.0, que lanzamos hace un año.

En resumen, las dificultades de trabajar en un comité no son mayores que las de cualquier proyecto distribuido. Además, la gente que los compone tiene un gran nivel y vienen con las reuniones muy bien preparadas.

¿Puedo trabajar en la versión 3.0 apuntando a un contrato 2.0?

En el cambio de versión ha habido ruptura de compatibilidad porque había que reorganizar el estándar e implicaba una mejora muy importante. Sin embargo, próximamente vamos a publicar la versión 3.1, y en esta no va a haber ningún tipo de ruptura ya que somos especialmente cuidadosos de añadir nuevas definiciones que sean interoperables con las versiones anteriores.

¿Yo, como una persona física puedo aportar a la iniciativa OpenAPI?

Si. La manera más normal es acceder al proyecto en GitHub de la especificación y dar de alta una Issue en donde describir al detalle la petición o la aportación que quieres añadir. El comité técnico semanalmente revisa el proyecto en GitHub y, aquellas que son interesantes de desarrollar, puede solicitarte que hagas una contribución (pull request) en donde definas la implementación técnica de la propuesta o abrir una nueva tarea interna para planificar su debate y construcción.

También en el proyecto en GitHub tenemos los documentos de cada una de las reuniones del comité para poder hacer un seguimiento de alguna propuesta o del trabajo realizado, así como del roadmap de la siguiente versión que se está “cocinando”.

Por ejemplo, en la futura versión 3.1 se describen los “Overlays” que permiten extender la descripción de la API, y que podrían valer para publicar la documentación de una misma interfaz en varios idiomas; o sistemas de encriptación y firmas digitales utilizando JWE (JSON Web Encryption).

Estando previsto hacer el anuncio de esta nueva versión el próximo 24 de septiembre en la conferencia “API Strategy & Practice”.

¿Qué aportaciones habéis hecho al estándar?

Desde la Universidad de Sevilla hemos propuesto un par de herramientas para el prototipado rápido de contratos con OpenAPI. Oas-generator y Oas-tools.

A titulo personal desarrollo una librería en TypeScript (openapi-ts) y otra en .Net CORE para la creación de contratos OpenApi 3.0.x, otra que construye definiciones 3.0 para Baucis (framework de construcción de APIs REST).

Además de publicaciones en el blog de la iniciativa, como el de “Tres escenarios comunes para aprovechar la especificación OpenAPI”, y la participación semanal en el comité técnico.

Más información | Iniciativa OpenAPI de la Fundación Linux, GitHub de OpenAPI, Página de la ISA en la Universidad de Sevilla

El café humea en la mesa, mientras el tono de llamada del Hangout se repite en mis auriculares, y repaso las preguntas que quiero hacerle a Pedro J. Molina; uno de los mayores expertos en OpenAPI de nuestro país.

Es miembro del ISA – Grupo de investigación de Ingeniería de software aplicada– de la Universidad de Sevilla, liderado por Antonio Ruiz junto a Pablo Fernández, y doctor en informática, especializado en modelado y generación de código.

Recientemente se ha integrado dentro de la Iniciativa OpenAPI, en donde participa de forma activa en la TSC (Technical Steering Committee) y el BGB (Business Governance Board). Y se ha prestado para una larga entrevista donde repasamos esta tecnología.

Una de las cosas que más me llaman la atención de Pedro, es la claridad y sencillez con que contesta las preguntas técnicas de todo nivel que le voy lanzando durante esta hora larga de conversación.

Busca la forma de explicar conceptos muy complejos, para lograr que lleguen a la mayoría de los lectores sin perder, en ningún momento, la rigurosidad de una mente científica.

¿Qué es OpenAPI?

Es un estándar para definir contratos de Api. Los cuales describen la interfaz de una serie de servicios que vamos a poder consumir por medio de una signatura. Por ejemplo, saber que vamos a tener una operación de sumar que va a recibir dos números y que estos son del tipo “entero”.

Tecnologías previas, como CORBA o SOAP, han intentado estandarizar las operaciones RPC (Llamadas a procedimientos remotos) que satisfagan la necesidad de comunicar dos máquinas que están separadas entre sí; y que requieran conocer como una tiene que invocar a la otra, especificando qué tipo de mensajes se aceptan, y qué es lo que se va a devolver.

¿Qué ventaja tiene el enfoque de OpenApi en comparación con definir un API de modo informal?

Se puede exponer un servicio de manera informal, pero la comunicación de cómo acceder al mismo también lo será.
Esta comunicación informal puede inducir o incluir equivocaciones al escribirla, describirla, o ser incompleta; siendo una documentación con muy poco valor para poder consumir el servicio, porque depende de que esté bien expresado y sea bien entendido.

Si hacemos el esfuerzo de formalizar esa definición (contrato), podemos conseguir que una máquina también la aproveche para poder conectarse al servicio y, consumiendo la especificación OpenAPI, construir un Proxy de integración. Es decir, una clase que automáticamente se conecta al servicio.

¿Pero esto no lo hacía ya los WSDL? ¿Qué falló para que sean tecnologías residuales en la actualidad?

CORBA y WSDL son tecnologías para comunicar servicios distribuidos. El paradigma SOA (Arquitectura orientada al servicio) es un estilo arquitectónico basado en la comunicación entre servicios distribuidos débilmente acoplados y altamente interoperables. SOA fue abrazado por la industria y los grandes fabricantes como Oracle, Microsoft, IBM, etc., los cuales se lanzaron a construir sus propias pilas de productos SOA que resultaron ser muy complejas y, en ocasiones, incompatibles entre sí.

Al final la complejidad del uso de la pila de productos SOA fue tal, que la industria abandonó la aplicación de los estándares más farragosos. Y con la llegada de los primeros smartphone y sus limitadas capacidades de cálculo y almacenamiento, migraron del XML al JSON (aunque el primero es mucho más extensible que el segundo) y de los Webservices (y sus sobres SOAP) a las comunicaciones REST.

¿Qué relación tiene Swagger con OpenAPI?

A finales de la década pasada empezó a crecer la economía de las API’s, la cual indica que toda aplicación que quiera escalar y triunfar en el mercado debe incluir una Interfaz de Programación de Aplicaciones potente.

En 2011, Tony Tam crea el proyecto Swagger API para automatizar la documentación y la generación del SDK (framework de desarrollo) de clientes de sus API’s. Diseñando un formato muy sencillo para describir el interfaz, en JSON o YAML, pero lo suficientemente formal como para que las máquinas lo puedan utilizar para crear Proxys (para clientes) y Skeletons (para servidores).

El éxito de Swagger fue fulgurante, convirtiéndose en un estándar “de facto”, y siendo adquirido por la empresa SmartBear que ha liberado todo el proyecto añadiéndolo a la Linux Foundation y atrayendo a los actores más importantes en la industria como Microsoft, IBM, PayPal, Adobe, Google, SAP, etc.

Y dentro de la Linux Foundation está la Iniciativa OpenAPI que es un comité dentro de la Fundación Linux que rige la evolución de la especificación.

¿Por qué está siendo tan apoyado por los fabricantes?

Si bien Swagger ya era libre, SamrtBear lo adquirió y liberó para hacerlo realmente neutral y que los diferentes fabricantes pudieran desarrollar sus ‘API Middleware’ -productos que se colocan entre tu API y el cliente final-, que te dan servicios de autenticación, autorización, seguridad, identificación, gestión de pagos, entre otros.

En una API que soporte 100 endpoints, la complejidad viene al tener que configurar nuestra herramienta para cada uno de ellos. Sin embargo, al tener una definición del contrato OpenAPI, con un sistema de drag & drop podría configurar de modo automático la herramienta de forma muy sencilla.

Los fabricantes de Middelware son los primeros interesados en que haya un estándar abierto para todos. Y, como hay negocio, se han puesto de acuerdo en dicho estándar siendo este el incentivo que ha conseguido que todos estén convergiendo hacía OpenAPI; incluso los usuarios de RAML, otro framework para definir las API, que se ha integrado en el comité de la Fundación Linux.

Pero no se circunscribe a los fabricantes, también actores tan importantes como la Banca o los gobiernos han entendido las ventajas de la estandarización en OpenAPI . Así Holanda se ha convertido en el primer estado que ha adoptado la definición para el desarrollo de sus aplicaciones.

¿Quién compone OpenAPI?

Hay una representación por cada organización que es miembro de la iniciativa. España está presente por el Grupo de investigación de Ingeniería de software aplicada (ISA) de la Universidad de Sevilla, al igual que por la startup 42 Crunch dedicada a la seguridad y gestión de amenazas a aplicaciones y datos.

El Grupo ISA hace una labor de investigación, más que orientada al negocio, trabajando en métricas de SLA donde se determina la definición de nivel de servicio. El objetivo es proponer extensiones orientadas a la medición y definición de niveles de servicio dentro de los contratos OpenAPI, aplicando la investigación realizada en la implantación industrial.

NdE. Las ramificaciones e implantaciones de estas extensiones al estándar OpenAPI aporta un valor crítico en las capacidades de aplicación de los contratos entre los interfaces de integración. En ningún otro estándar se comprende de manera específica el soporte a la medición de la calidad del servicio.

Dentro de la iniciativa OpenAPI existen tres comités diferenciados:

• El Comité Técnico, en donde se discute el estándar y se añaden extensiones. Se trabaja con reuniones semanales en donde se revisa el estado de los desarrollos.
• Comité de Gobierno, en donde se revisa el estado de la iniciativa desde un punto de vista de gestión.
• Comité de Marketing, donde se diseñan y ponen en marcha acciones de formación, difusión, visibilización, etc. Y que utiliza los fondos aportados por las organizaciones miembros para realizar los eventos o campañas.

Además, de un par de personas a tiempo completo en la Linux Foundation, dedicadas a OpenAPI.

¿Cuáles son los mayores impedimentos que te encuentras en el día a día al trabajar en los comités?

Hay que conciliar los intereses de muchos fabricantes, que cada uno quiere añadir sus propias funcionalidades, las cuales hay que discutir y acordar. Todas las cosas diseñadas por comité son un poquito más lentas que cuando swagger lo construían dos personas y añadían funcionalidad muy rápido, llevando el producto hacia donde querían.

Lo bueno es que al estar integrado en la Linux Foundation se garantiza que todo lo que se aporta está libre de patentes y que todo el mundo lo va a poder utilizar sin restricciones.

Hay veces que nos gustaría sacar las cosas más rápido, pero es necesario priorizar los temas, y los procesos van un poquito más despacio. Es importante ser cautos con las publicaciones para dar tiempo que la industria implemente estos estándares.

Por ejemplo, aún hay muchos utilizando OpenApi 2.0 mientras esperaban herramientas en desarrollo para la versión 3.0, que lanzamos hace un año.

En resumen, las dificultades de trabajar en un comité no son mayores que las de cualquier proyecto distribuido. Además, la gente que los compone tiene un gran nivel y vienen con las reuniones muy bien preparadas.

¿Puedo trabajar en la versión 3.0 apuntando a un contrato 2.0?

En el cambio de versión ha habido ruptura de compatibilidad porque había que reorganizar el estándar e implicaba una mejora muy importante. Sin embargo, próximamente vamos a publicar la versión 3.1, y en esta no va a haber ningún tipo de ruptura ya que somos especialmente cuidadosos de añadir nuevas definiciones que sean interoperables con las versiones anteriores.

¿Yo, como una persona física puedo aportar a la iniciativa OpenAPI?

Si. La manera más normal es acceder al proyecto en GitHub de la especificación y dar de alta una Issue en donde describir al detalle la petición o la aportación que quieres añadir. El comité técnico semanalmente revisa el proyecto en GitHub y, aquellas que son interesantes de desarrollar, puede solicitarte que hagas una contribución (pull request) en donde definas la implementación técnica de la propuesta o abrir una nueva tarea interna para planificar su debate y construcción.

También en el proyecto en GitHub tenemos los documentos de cada una de las reuniones del comité para poder hacer un seguimiento de alguna propuesta o del trabajo realizado, así como del roadmap de la siguiente versión que se está “cocinando”.

Por ejemplo, en la futura versión 3.1 se describen los “Overlays” que permiten extender la descripción de la API, y que podrían valer para publicar la documentación de una misma interfaz en varios idiomas; o sistemas de encriptación y firmas digitales utilizando JWE (JSON Web Encryption).

Estando previsto hacer el anuncio de esta nueva versión el próximo 24 de septiembre en la conferencia “API Strategy & Practice”.

¿Qué aportaciones habéis hecho al estándar?

Desde la Universidad de Sevilla hemos propuesto un par de herramientas para el prototipado rápido de contratos con OpenAPI. Oas-generator y Oas-tools.

A titulo personal desarrollo una librería en TypeScript (openapi-ts) y otra en .Net CORE para la creación de contratos OpenApi 3.0.x, otra que construye definiciones 3.0 para Baucis (framework de construcción de APIs REST).

Además de publicaciones en el blog de la iniciativa, como el de “Tres escenarios comunes para aprovechar la especificación OpenAPI”, y la participación semanal en el comité técnico.

Más información | Iniciativa OpenAPI de la Fundación Linux, GitHub de OpenAPI, Página de la ISA en la Universidad de Sevilla