OpenAPI, estandarizando los contratos de las API. Entrevista a Pedro J. Molina

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

Es miembro del ISA – Conjunto de investigación de Ingeniería de software aplicada- de la Universidad de Sevilla, dirigido por Antonio Ruiz al lado de Pablo Fernández, y doctor en informática, experto en modelado y generación de código.

Últimamente se ha integrado en 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 responde las preguntas técnicas de todo nivel que le voy lanzando a lo largo de esta hora larga de charla.

Busca la manera de explicar conceptos muy complejos, para conseguir que lleguen a la mayor parte de los lectores sin perder, en ningún instante, la rigurosidad de una psique científica.

¿Qué es OpenAPI?

Es un estándar para delimitar contratos de Api. Los que describen la interfaz de una serie de servicios que podremos consumir a través de una signatura. Por servirnos de un ejemplo, saber que tendremos una operación de sumar que recibirá 2 números y que estos son del tipo “entero”.

Tecnologías anteriores, como CORBA o bien SOAP, han intentado normalizar las operaciones RPC (Llamadas a procedimientos recónditos) que satisfagan la necesidad de comunicar 2 máquinas que están separadas entre sí; y que requieran conocer como una debe invocar a la otra, detallando qué género de mensajes se admiten, y qué se devolverá.

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

Se puede exponer un servicio de forma informal, mas la comunicación de de qué forma acceder al mismo asimismo lo va a ser.
Esta comunicación informal puede inducir o bien incluir equivocaciones al escribirla, describirla, o bien ser incompleta; siendo una documentación con poquísimo valor para poder consumir el servicio, por el hecho de que depende de que esté bien expresado y sea bien entendido.

Ese es el contrato en que hay que ponerse conforme.

Si hacemos el ahínco de formalizar esa definición (contrato), podemos lograr que una máquina asimismo la aproveche para poder conectarse al servicio y, consumiendo la especificación OpenAPI, edificar un Proxy de integración. Esto es, una clase que de manera automática se conecta al servicio.

¿Mas esto no lo hacía ya los WSDL? ¿Qué falló a fin de que sean tecnologías residuales actualmente?

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 endeblemente acoplados y enormemente interoperables. SOA fue abrazado por la industria y los grandes fabricantes como Oracle, Microsoft, IBM, etcétera, los que se lanzaron a edificar sus pilas de productos SOA que resultaron ser realmente complejas y, a veces, incompatibles entre sí.

Al final la dificultad del empleo de la pila de productos SOA fue tal, que la industria abandonó la aplicación de los estándares más confusos. Y con la llegada de los primeros móvil inteligente y sus limitadas capacidades de cálculo y almacenaje, migraron del XML al JSON (si bien el primero es considerablemente 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?

OpenAPI viene de Swagger.

A fines de la década pasada comenzó a medrar la economía de las API’s, la que señala que toda aplicación que desee escalar y triunfar en el mercado debe incluir una Interfaz de Programación de Aplicaciones potente.

En dos mil once, Tony Tam crea el proyecto Swagger API para mecanizar la documentación y la generación del SDK (framework de desarrollo) de clientes del servicio de sus API’s. Diseñando un formato sencillísimo para describir la interfaz, en JSON o bien YAML, mas suficientemente formal para que las máquinas lo puedan usar para crear Proxys (para clientes del servicio) y Skeletons (para servidores).

El éxito de Swagger fue brillante, transformándose en un estándar “de facto”, y siendo adquirido por la compañía SmartBear que ha liberado todo el proyecto añadiéndolo a la Linux Foundation y atrayendo a los actores más esenciales en la industria como Microsoft, IBM, Paypal, Adobe, Google, SAP, etcétera

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

¿Por qué razón es tan apoyado por los fabricantes?

Aunque Swagger ya era libre, SamrtBear lo adquirió y liberó para hacerlo verdaderamente neutral y que los diferentes fabricantes pudiesen desarrollar sus 'API Middleware' -productos que se ponen entre tu API y el usuario final-, que te dan servicios de autentificación, autorización, seguridad, identificación, administración de pagos, entre otros muchos.

En una API que soporte cien endpoints, la dificultad viene al tener que configurar nuestra herramienta para cada uno de ellos de ellos. No obstante, al tener una definición del contrato OpenAPI, con un sistema de drag