OpenAPI y la necesaria estandarización de las APIs

La ingeniería informática es una de las ingenierías más jóvenes. Es bueno tenerlo bien presente cada vez que la comparamos con otras ingenierías con más solera que han tenido más tiempo para estandarizar sus procedimientos y buenas prácticas.

Cuando una ingeniería madura, surgen problemas recurrentes, patrones, mejores prácticas y finalmente procedimientos y estándares para resolver problemas de modo estandarizado y con garantías de calidad basados en experiencias contrastadas. En ingeniería eléctrica, por ejemplo, se estandarizó algo tan sencillo (y tan poco trivial políticamente hablando, por otro lado) como el enchufe: que nos permite, si no todavía de modo universal, si por países al menos, poder interconectar cualquier electrodoméstico a la red eléctrica.

Del lado de la informática, estamos inmersos en la era de la Web y de las APIs. Y tenemos APIs para consumir servicios muy diversos como: mapas, mensajería, información meteorológica, tráfico, contaminación, noticias, bolsa, transacciones monetarias entre empresas y particulares, inteligencia artificial, etc. La lista es interminable y empiezan a surgir directorios especializados en publicar y localizar servicios. APIs que podemos interconectar para crear servicios con valor añadido por el simple hecho de agregar y combinar información de diversos servicios para generar uno nuevo con mayor inteligencia.

Desde el lado del desarrollador, las APIs en la Web se publican en su mayoría usando tecnología REST sobre protocolos estándares como HTTP/HTTPS con mucha frecuencia codificadas usando JSON y en menor medida con XML y otro tipo de formatos binarios como Protobuf o Avro.

Para poder descubrir y llegar a poder usar estas APIs, los desarrolladores necesitan documentación que les permita comprender el valor aportado y los detalles técnicos involucrados.

Ante esta necesidad y la explosión de APIs disponibles, comenzaron a surgir hace ya unos años estándares para la descripción de APIs como RAML, API Blueprint, Swagger, WADL o Slate (pequeña comparativa).

De todas ellas, es Swagger la que ha ido ganando terreno a pasos agigantados como estándar de facto industrial y fue cedida a la Linux Foundation bajo el nuevo nombre de OpenAPI Initiative para su evolución como un estándar neutral independiente de fabricante. Lo que nos lleva a la pregunta:

¿Es OpenAPI la nueva bala de plata para el desarrollo de APIs?

Desde luego que no. Si algo hay claro en informática es que no existe la bala de plata, no hay una única solución ideal aplicable a todos los problemas.

Sin embargo, desde el punto de vista de los sistemas interoperables, que deben perdurar a lo largo del tiempo aunque la tecnología cambie, definir contratos estándar del modo más sencillo posible tiene mucho valor para garantizar que podrá seguir siendo accedido en el futuro desde nuevos lenguajes y versiones de protocolos.

Recientemente el Gobierno de Holanda ha seleccionado OpenAPI versión 3.0 como estándar para la publicación de todos su APIs gubernamentales. Es un pequeño paso para garantizar esta interoperabilidad.

Tiene sentido, porque la estandarización supone menores adaptaciones entre APIs y mayor interconectividad.

Ojalá, más empresas privadas, gobiernos y organismos oficiales se sumen pronto a esta senda para acelerar sus estrategias entorno a datos abiertos (OpenData) y una mayor transparencia en el gobierno.

En los años 60 ocurrió una revolución el comercio mundial. El responsable fue la estandarización del contenedor para el transporte de mercancías marítimo. ¿Es la única manera posible de empaquetar bienes? Desde luego que no, pero disponer de un estándar común admitido en todo el mundo capaz de ser transportado del mismo modo por mar, aire y tierra supuso un abaratamiento enorme de los gastos de transporte y un impulso al comercio.

Del mismo modo, en un mundo digital, donde la información y los servicios digitales están en auge (Economía de APIs), la estandarización de las APIs aporta el sustrato necesario para simplificar la complejidad técnica hasta el punto de ofrecer la interconexión con un nuevo servicio como una commodity, con costes despreciables. Y permitir que florezcan nuevos servicios y productos que no podrían ni plantearse sin estas condiciones.