OpenApi v3

Parece que la Linux Foundation está haciendo su trabajo y la versión 3 de la especificación Open API (también conocido como Swagger) va tomando forma.

Una buena forma de ir poniéndose al día con esos avances es seguir la serie de artículos que los miembros del Technical Developer Community están publicando.

Por mi parte me llaman la atención estos aspectos:

• El proceso es bastante abierto y se puede seguir las discusiones en GitHub, por ejemplo, las relativas a seguridad o a protocolos.
• Aparte de cambios estructurales (parece que principalmente para agrupar más elementos y que no haya tantos en la raíz del documento), se añade soporte a los famosos webhooks/callbacks

Y me hace plantearme las siguientes cuestiones:

• Una de las principales ventajas que veía a Swagger sobre otros lenguajes de especificación de APIs como RAML o Blueprint, es que existe un gran número de herramientas compatibles con este estándar, pero … ¿cuando van a estar todas esas herramientas actualizadas?
• ¿qué pasará con los gestores de APIs? Y no sólo me refiero a que soporten la nueva estructura , la pregunta es: ¿soportarán todas las nuevas características?
  • Por ejemplo, nuestro gestor de API mantendrá unas analíticas de las llamadas a las APIs, tanto para auditoría como para la tan ansiada monetización. Hasta ahora, con un simple modelo basado en petición/respuesta era suficiente. Pero, ¿y si quiero ver cuantas llamadas al webhook se han producido?, ¿y si quiero monetizar no en función del número de veces que me ha invocado mi cliente y lo quiero hacer en función de las veces que he invocado yo a su webhook? Cuando el fabricante de nuestro gestor de APIs nos diga que soporta OpenAPIv3, ¿habrá tenido esto en cuenta y rediseñado su modelo de analíticas y monetización para ello?
  • ¿obligará lo anterior a que cuando en nuestro backend se dispare las condiciones y se genere el evento, en vez de invocar directamente a la URL del callback se pase por una pieza intermedia para añadir esa monitorización a la base de datos del gestor de APIs?
  • ¿es esta pieza el API Gateway? ¿es el sitio adecuado para ello? En organizaciones con información muy sensible, una tarea que se suele gobernar desde la gestión de APIs y que se encomienda al API Gateway es la ofuscación y redacción de los mensajes. Si aplicamos dicho criterio a un protocolo petición/respuesta, también lo querremos aplicar a un protocolo de suscripción. Imaginemos que nuestro sistema almacena números de tarjetas bancarias, pero que ninguna de nuestras APIs públicas devuelven ese dato. Si somos paranoicos responsables, aprovecharemos las capacidades de nuestro software de gestión de APIs para que borre esa información si detecta un patrón de número de tarjeta en alguna respuesta, fruto de algún intento de cracking o bug de nuestro software. Y esto es algo que debemos aplicar tanto cuando devolvemos la respuesta en el momento, como cuando lo hacemos a posteriori con una callback.