IBM API Connect

Onboarding en API Connect

A continuación describimos el funcionamiento de la herramienta API Connect y sus principales características.

¿Qué es un API Manager?

Un API Manager gestiona el proceso de crear y publicar interfaces de programación de aplicaciones (API) web, haciendo cumplir sus políticas de uso, controlando el acceso, nutriendo a la comunidad de suscriptores, recopilando y analizando estadísticas de uso e informando sobre el rendimiento. Los componentes de API Management proporcionan mecanismos y herramientas para apoyar a la comunidad de desarrolladores y suscriptores.

¿Qué es API Connect?

API Connect es una plataforma de gestión de APIs construida sobre una arquitectura de microservicios que permite su desarrollo en un entorno multicloud, cuyas principales capacidades son: la creación, la seguridad, la gestión, test y monitorización, socialización y análisis.

API Connect se compone de 3 componentes:

· El API Management Node es quien controla el acceso a la plataforma de usuario final (puede ser el externo, partner o interno) dividiendo los roles de usuarios y desarrolladores.

· El API Designer permite el diseño e implementación en local con un mini management y mini gateway para hacer pruebas locales.

· El API Gateway gestiona los scopes y el loopback app basado en Node.js permitiendo usar conexiones a bases de datos como Mongo o app externas como API Toolkit.

Conceptos generales

API Connect es una plataforma web para la creación, exposición y gestión de APIs.

Los productos se utilizan para ofrecer una o más APIs a los posibles consumidores, el control de acceso a las APIs se realiza a través de los planes. Los productos son paquetes que contienen APIs y planes.

Para exponer una API es necesario que esté incluida en un producto y que a su vez el producto contenga un plan.

A través de los planes se controla que desarrolladores pueden acceder a las APIs, qué operaciones de las APIs están disponibles y establecer rate limits a las APIs.

Los productos además de contener las APIs y los planes, se utilizan para administrar el ciclo de vida de las APIs a través de los estados: draft, staged, published, deprecated, retired, y archived. Un producto en estado draft se mueve al estado stage cuando el producto se guarda en el catálogo y se mueve al estado published cuando su catálogo es publicado, momento en el que las APIs estarán disponibles para los desarrolladores.

Los catálogos son colecciones de productos usados para publicar estos en el Developer Portal. Se utilizan también para tener distintos "entornos", por ejemplo un catálogo de testing para probar las APIs antes de llevarlas al catálogo de producción. Cata catálogo tiene asociado un Developer Portal, para exponer los productos publicados, y también tiene asociado un gateway service, para procesar las operaciones de las APIs expuestas en el catálogo.

Por último, el DataPower Gateway proporciona un amplio rango de políticas que se incorporan en el ensamblaje de API de API Connect, lo que incluye transformaciones, políticas de seguridad, lógica y GatewayScript (basado en JavaScript).

Organización

En API Connect, hay dos tipos de organizaciones o roles: proveedor y desarrollador.

Una organización proveedora es propietaria de APIs, planes y productos asociados, y además puede poseer aplicaciones de proveedor (backends en node o Java) que son llamadas por las APIs. Se encarga de gestionar los ciclos de vida de las API y publica las APIs.

Una organización de desarrolladores es propietaria sólo de aplicaciones de desarrollador, y consumidor de las APIs y aplicaciones producidas por la organización proveedora.

Casos de uso

1. Propiedades

En ocasiones, querremos hacer uso de variables que dependen del entorno (catálogo) donde están desplegadas, por ejemplo, la url de un target, que será distinta en pre que en pro. Estas variables se almacenarán en la sección “propiedades” del API y se podrán consultar en cualquier punto del ensamblador usando la sintaxis $(nombre-variable), excepto en los gateway-script donde la llamaremos como al resto de variables de contexto con un apim.getvariable(‘nombre-variable’).

2. Id único por petición

Api Connect añade automáticamente la cabecera X-Global-Transaction-Id a todas las peticiones, la cabecera viajará al target y se devolverá al cliente. Su valor es un identificador único de petición. Por defecto no se envía al cliente, sólo al target, para que esto ocurra debemos usar la primera política de la plantilla que almacena el valor de X-Global-Transaction-Id y la última política del ensamblador que lo añade a la respuesta al cliente.

3. Transformación XML-JSON o JSON-XML

Para realizar esta transformación, llamaremos al target en invoke-json, ejecutaremos la política parse-json, que transforma el body recibido del target en formato json a una entidad json que entiende la última política: json-xml, que transformará el json en xml y al contrario para transformación xml-json.

Odoo text and image block

4. GatewayScripts

Mediante los gatewayscript podremos introducir nuestro propio código javascript, con el cual podremos desarrollar muchas funcionalidades.

En ocasiones, el path que exponemos es distinto al path del target y queremos transformar la salida de la petición.

Podremos realizar esa transformación accediendo a los parámetros del path en un gatewayscript y seteando el nuevo path en una variable que será llamada desde el invoke en el que realicemos la petición.

O añadir condicionales para setear si se cumple cierta condición.

Podemos encriptar y desencriptar el body u otras variables mediante distintos mecanismos de cifrados, como AES o 3DES.

También podremos capturar el valor de una variable y setear nuevas variables, entre otras muchísimas opciones.

Odoo text and image block

5. Mapeos

Mediante la transformación Correlación podemos cambiar nuestro cuerpo de salida para que coincida con la respuesta deseada o bien prepararlo para llamar a otro target.

Y mapear el resultado en el formato deseado, por ejemplo XML, JSON, o texto plano.

6. Caché

En Api connect no se dispone de una base de datos en la que almacenar fragmentos de información como en otros api managers. Lo que sí es posible es que la política invoke, que realiza las llamadas http almacene en caché las respuestas de las peticiones usando como key la url u otro valor configurable. De forma que la segunda vez que realiza la misma llamada, la recupere de caché en lugar de recurrir a la conexión http.

Se activa en la configuración de la política invoke, donde activaremos la caché usando la Cache Type “Tiempo de vida”, y definiremos el tiempo que permanece cualquier valor cacheado.

El cliente podrá desactivar la caché enviando una cabecera (por ejemplo Cache-Control: no-cache).

La política invoke, por defecto, cachea siguiendo las indicaciones de la RFC al estar configurada como Cache Type: “Protocolo”; como normalmente no existen las cabeceras de control de Caché esta no se realizará.

Si queremos impedirlo debemos configurar el Cache Type a “Sin Memoria Caché”.

Analítica y Logging

Cualquier llamada que pase por el gateway genera un registro de log con información de la request, no es necesario configurar nada para que esto ocurra, IBM Api Connect lo hace por defecto.

En principio, la información completa de la llamada (payload, headers...), sólo se registra para llamadas erróneas (status diferente de 2xx). Para llamadas correctas se registra menos información (uri, latencias y otra información básica). Este comportamiento se puede modificar configurando el activity-log de la API que sobrescribe la configuración por defecto.

Esta configuración nos permite establecer aquello que se almacenará en caso de error y lo que se almacenará en caso contrario:

None: no almacenar nada.
Activity: el recurso de la URI y otra información básica (por defecto para peticiones satisfactorias).
Header: lo anterior y cabeceras.
Payload: lo anterior y el cuerpo (por defecto para peticiones erróneas).

Esta información se explota después desde las analíticas del catálogo.

Autenticación

Api connect permite infinidad de opciones para implementar mecanismos de seguridad y de OAuth. Se puede optar por un proveedor de OAuth nativo que use una URL de autenticación en un servidor externo. Para realizarlo necesitaremos varios recursos, como es un registro de usuarios y proveedores de OAuth.

Una vez hecho esto, si queremos que una API esté protegida por OAuth, bastará con crear una definición de seguridad de tipo OAuth, que tenga como proveedor el creado anteriormente. Y después proteger los endpoints con esta definición de seguridad desde cada vía de acceso o bien dejarlo de forma general para el proxy.

Conclusiones

El primer aspecto a destacar, es la estabilidad de la herramienta y las actualizaciones que recibe. Por otro lado, la herramienta cuenta con muchas funcionalidades satélite que otros API Manager no tiene, como un developer portal, una cantidad de políticas extenso (transformaciones) etc.

En comparación con otros API Manager, es muy competitivo en precios, a pesar de ser una aplicación de IBM, llega a ser más barato incluso que otros APIM que son open source.

Por último, el único problema importante que hemos tenido es la documentación escasa y la poca comunidad que encontramos alrededor de esta herramienta.

En resumen, API Connect cumple con su cometido con muy buena nota a nuestro parecer y es una alternativa relevante a la hora de realizar un gobierno de API.