Si como proveedor de APIs ya hemos seguido los pasos para hacer la publicación de nuestra API para Salud en Nubentos, estamos en el momento más emocionante: pronto llegarán los primeros consumidores de nuestra API. Pero ¿qué debemos saber sobre la gestión de las suscripciones, accesos y versiones de la API para tener un control total de su uso?. En este artículo te lo contamos.

Control de accesos a tu API para Salud

La plataforma Nubentos proporciona gran cantidad de información y posibilidades para gestionar el consumo que realizan nuestros clientes. A continuación realizaremos un repaso sobre los principales aspectos.

Si accedemos a la plataforma con el perfil consultor iremos directamente a la pantalla de APIs y a continuación al resumen de nuestra API para Salud.

 

Lo primero que vemos es que nuestra API ya está publicada y que ya tiene dos usuarios suscritos.

Podemos ir a la pestaña de “Users” para ver qué uso están haciendo de la API.

 

Podemos identificar que existen dos usuarios, en qué fecha se han registrado y qué uso están haciendo de la API. 

Control de suscripciones de tu API para Salud

Si por alguna razón nos vemos obligados a bloquear el acceso de un usuario a nuestra API para Salud, tenemos dos posibilidades. La primera es bloquear el acceso al entorno de producción dejando el entorno de sandbox (pruebas) disponible. La segunda es bloquear el acceso por completo a todos los entornos. 

Para hacer esto, en el menú de la izquierda seleccionamos la opción “MANAGE SUBSCRIPTIONS”, que nos mostrará la relación de los usuarios suscritos a la API. Seleccionando en el desplegable el suscriptor, podremos bloquear el acceso.

 

Del mismo modo, podremos habilitar el acceso cuando lo consideremos necesario.

Desde el punto de vista de las aplicaciones que hacen uso de la API, mientras esté bloqueada la suscripción las peticiones que realicen recibirán la siguiente respuesta:

 

 

El bloqueo de las peticiones al gateway se realiza en tiempo real, pero debemos tener en cuenta que tarda cierto tiempo en propagarse a todos los nodos de gateway y que se tiene que cumplir el tiempo de expiración de las caches (un máximo de 15 minutos).

Para rescindir todos los permisos de acceso de un usuario con el perfil de consumidor es necesario contactar con el soporte de Nubentos.

Control desde el Ciclo de Vida de la API

Las suscripciones que tiene una API también se verán afectadas por ciertos cambios en el ciclo de vida de la API. Si una API pasa a estado BLOCKED las suscripciones quedarán suspendidas y al realizar una petición recibirán la siguiente respuesta:

 

 

Otro de los casos especiales que se dan cuando gestionamos el ciclo de vida de una API, es que todos los usuarios suscritos a una API de una versión determinada serán automáticamente suscritos a la nueva versión, a menos que indiquemos lo contrario en el proceso de publicación, quedando en manos de los desarrolladores apuntar al nuevo endpoint.

 

En esta captura vemos como todos los suscriptores han sido clonados en la nueva versión de la API.

¿Cómo gestionar el cambio de versión de una API para Salud? 

Uno de los aspectos importantes que tenemos que tener en cuenta cuando gestionamos  una API en “Producción” y que está siendo consumida, es cómo hacer la publicación de una nueva versión de una API.

Debemos notificar a todos los consumidores de la versión anterior que hemos puesto a su disposición una nueva versión, y redirigirlos a la documentación de la API para que vean el Roadmap de la misma. De esta forma sabrán cuándo se retirará la versión actual forzando de esta forma a todos los consumidores a usar la nueva versión.

Para promover una nueva versión de la API publicada después de que el equipo de desarrollo haya hecho los cambios, debemos acceder al API Publisher de Nubentos con el perfil consultor.

Aparecerán dos iconos con las distintas versiones de la API. 

Podemos ver que la API actualmente publicada es la versión “1.0.0” y que tiene dos usuarios suscritos, mientras que la nueva versión “1.0.1” aún está en estado “CREATED” y no tiene ningún suscriptor.

Pulsaremos sobre el detalle de la API de la versión 1.0.1 y a continuación sobre la pestaña de “Lifecycle” . 

Tenemos dos checks que influyen en cómo se hace el traspaso de subscripciones desde la API de la versión 1.0.0 a la nueva versión que vamos a publicar. 

El primero es “Deprecate old version after publish the API”, e implica que todos los usuarios suscritos a la versión 1.0.0 perderán su suscripción y la API de esa versión no estará disponible.

El segundo es “Requires re-subscription when publish the API”, que forzará a todos los suscriptores de la versión 1.0.0 a tener que volver a subscribirse a la nueva versión.

Si no marcamos ninguno de los check y pulsamos sobre el botón “PUBLISH”, la API de la nueva versión será publicada y tendrá de partida dos nuevas suscripciones con los mismos usuarios que la versión previa.

 

Tenemos que tener en cuenta que cada API tiene un endpoint distinto ya que la versión forma parte de la URL del endpoint.

 

Desde el punto de vista de los consumidores, en el listado de suscripciones que tienen asociada a su aplicación aparecerá una distinta por cada versión de la API.

 

Está en manos del usuario consumidor desactivar la suscripción (Unsubscribe)  con la versión previa cuando su aplicación haya sido adaptada a la nueva versión.

Dejamos para un próximo artículo los pasos que debemos seguir para retirar la versión antigua de una API y qué precauciones debemos tener para no afectar a las aplicaciones que están consumiendo nuestra API.