Onboarding en API Connect
¿Qué es un API Manager?
¿Qué es un API Manager?
Conceptos generales
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.
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
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.
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.
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.
Odoo text and image block
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.
Blog realizado por V. Javier Gonzalez, Alberto González y Oriol Brau.
¡Habla con nuestros expertos!
