Flows

¿Qué son los flujos de APIs?

La arquitectura para exposición de APIs ampliamente adoptada en el mercado prevé la separación de responsabilidades, donde la presencia de un gateway de APIs como elemento intermediario entre los clientes y los servicios en servidores es fundamental.

Por defecto, todos los datos de una petición (request) son pasados sin modificaciones para el servidor, apuntado por el enrutamiento del gateway. Lo mismo sucede con la respuesta (response) enviada por el servidor. Por defecto, todos los datos de la respuesta son pasados sin modificaciones para el cliente que originó la petición.

Sin embargo, hay diversas situaciones donde es necesario modificar los datos de la petición antes de enviarla al servidor, o modificar la respuesta estándar que será devuelta al cliente. Por ejemplo, un usuario puede desear:

  • adicionar informaciones a la petición antes de enviarla al servidor (enriquecimiento de mensajes);

  • recuperar información específica (para identificar el origen de la petición, por ejemplo);

  • retirar o mascarar informaciones sensibles que no deben ser almacenadas en logs;

  • tomar decisiones de rutas con base en el contenido de los mensajes;

  • componer más de una llamada a servicios internos en una misma petición externa.

La definición de una API incluye la configuración de los flujos de entrada y salida de los mensajes. En el camino de estos flujos, pueden ser adicionados interceptores en puntos específicos, que serán ejecutados en un orden bien definido. Los interceptores son los elementos que ejecutan lógicas y establecen comportamientos específicos.

La ejecución de los interceptores sigue una jerarquía en árbol, respetando el orden de su configuración.

A continuación, un escenario donde los interceptores son adicionados en los flujos de entrada y salida de los mensajes:

flow all interceptor

Puede agregar interceptores estándar (que ya están listos para usar en su Manager) o interceptores personalizados a sus flujos de APIs. Acceda a esta página para leer acerca de los interceptores disponibles.

Cómo configurar flujos de API

En la configuración del flujo, pueden ser definidos:

  1. El alcance de la ejecución del flujo, que incluye:

    • Resources: exhibe todos los recursos de la API. Cuando es seleccionado "All", el flujo se aplicará en todos los recursos. flow resource interceptor

    • Operations: exhibe todas las operaciones para el recurso seleccionado. Sigue el mismo concepto de los recursos: si es seleccionado "All", se aplicará en todas las operaciones de un recurso. flow operation interceptor

  2. El conjunto de interceptores, que se dividen en: Traffic, Security, Mediation, Tracing, Transformation, Custom.

  3. El punto de ejecución de la petición realizada desde el cliente para el servidor. El orden de los interceptores — de la izquierda para la derecha — define cómo será el procesamiento. Todos los interceptores son válidos para este punto de ejecución;

  4. El punto de ejecución de la respuesta retornada desde el servidor para el cliente, mediante algún procesamiento de los interceptores. El orden de ejecución de los interceptores es de la derecha para la izquierda. Algunos interceptores no forman parte de este punto de ejecución, como: Client ID Validation, Access Token Validation y OAuth.

  5. El destino (destination) de la API, que puede ser lo mismo para todas las peticiones a la API o específico para un dado recurso o operación (dependiendo de si ha elegido "All" en los campos Resources y Operations o si ha definido un recurso o operación específicos). Para configurar el destino, hacer clic en el botón icon backend, a través del cual también puede definir el certificado a utilizar y un tiempo de espera (timeout) específico.

Actualmente, el gateway hace uso de reutilización de conexiones por defecto, para más información sobre como gestionarla consulte esta página de nuestras preguntas frecuentes.
  • El timeout determina el tiempo límite de espera de consumo de un determinado recurso o operación. Cuando el tiempo de una petición exceda el valor del timeout configurado, la petición será abortada y una excepción será lanzada por el sistema con el status 502.

    • El timeout puede ser definido directamente a través de un valor en segundos en el campo Timeout, o a través de una variable de entorno.

    • El timeout presente en los destinos sigue una jerarquía de ejecución: es ejecutado desde el nivel más genérico para el más específico. Ejemplo: un timeout definido para "All" será replicado para todos los recursos y operaciones, al menos que sea definido un timeout diferente en un componente más específico.

      Para saber más sobre el funcionamiento del tiempo de espera, consulte esta página de nuestras preguntas frecuentes.
flow destination

API Destination

Path Params

Si se repite el nombre de un parámetro, el gateway repetirá el valor pero descartará el nombre del parámetro que se encuentra en el recurso, considerando únicamente el orden de los parámetros recibidos.

Ejemplos:

Teniendo en cuenta el recurso GET /path/{param1}/path/{param2}/path/{param3}, con la siguiente solicitud enviada /path/1/path/2/path/3:

  1. si el destination es GET /path/{param1}/path/{param2}/path/{param3}, el gateway reenviará a /path/1/path/2/path/3

  2. si el destination es GET /path/{param3}/path/{param2}/path/{param1}, el gateway reenviará a /path/1/path/2/path/3

  3. si el destination es GET /path/{param1}/path/{param2}/path/{param1}, el gateway reenviará a /path/1/path/2/path/1

  4. si el destination es GET /path/{param3}/path/{param2}/path/{param3}, el gateway reenviará a /path/1/path/2/path/1.

Headers

El header de Transfer-Encoding es removido desde el momento en que la solicitud viaja a través del gateway, tanto en response como en request. Para obtener más información sobre la eliminación de headers, haga clic aquí.

Herencia de flujos

Podemos crear varios flujos para una llamada a la API.

Los flujos siguen un modelo de jerarquía, o sea, los interceptores del padre serán heredados por sus hijos, pero las modificaciones en los hijos no serán reflejadas en el padre, conforme muestran las figuras anteriores.

Los interceptores heredados de un padre estarán en gris oscuro, mientras los propios estarán coloreados:

flow parent child

Quiebra de flujo

Una quiebra de flujo es caracterizada por una modificación en el orden de los interceptores heredados de un flujo padre. En este caso, las modificaciones hechas en los interceptores del flujo padre no serán pasadas para sus hijos.

¿Qué causa quiebra de flujo?

  • cambio del orden de los interceptores heredados del padre;

  • cambio del orden de los interceptores del hijo, al frente de los heredados del padre;

  • cambio del orden de los interceptores del hijo, en el medio de los heredados del padre;

  • adición de un nuevo interceptor, al frente de los interceptores heredados del padre;

  • adición de un nuevo interceptor, en el medio de los interceptores heredados del padre.

¿Qué NO causa quiebra de flujo?

  • Cambio del orden de los interceptores del hijo, después del interceptores del padre;

  • Adición de un nuevo interceptor, después de los interceptores heredados del padre;

  • Modificación de los valores de los interceptores del padre.

Los valores modificados en el hijo serán transmitidos para sus hijos herederos; sin embargo, si hubiere una modificación en el valor del padre, esta no será transmitida para los hijos ni para los hijos herederos.

La imagen a continuación representa un flujo hijo normal, donde los interceptores en gris son heredados y fue adicionado un interceptor de Log en el flujo de petición, obedeciendo el orden de los interceptores.

interceptors natural order

Enseguida tenemos un ejemplo de una quiebra de flujo. El orden de los interceptores fue modificado: fue adicionado un interceptor de Client ID Validation antes del primer interceptor heredado del flujo padre (Rate Limit). Así, cualquier modificación hecha en el flujo padre no será reflejada en el flujo en cuestión.

flow break

Es posible revertir la quiebra de flujo haciendo clic en el botón Restore localizado al lado del campo de selección Operations.

flow break restore

Alertas y preguntas comunes sobre flujos

  • A veces se intenta encontrar un interceptor para añadir al flujo y parece que falta. En estos casos, es interesante comprobar si el interceptor se puede utilizar para el ámbito seleccionado (API en su conjunto, nivel de recurso u operación).

  • Hay interceptores que se pueden agregar tanto al flujo de petición (request) como al flujo de respuesta (response), pero hay otros que solo se pueden arrastrar a uno de los flujos. Puede consultar la documentación específica del interceptor que desea configurar para obtener más detalles.

  • El orden de los interceptores en el flujo refleja el orden en que cada uno se aplicará a la llamada. Tenga esto en cuenta al arrastrar interceptores al flujo. Cuando se completa una llamada, puede comprobar la secuencia de ejecución del interceptor en los detalles del Trace (en General Trace  llamada deseada  pestaña GATEWAY TRACE).

  • Cuando desee editar el flujo de una API, no basta con guardar los cambios en la pantalla de edición del flujo. Cuando se le redirija a la pantalla de resumen de la API, deberá guardar la propia API.

  • Solo es posible identificar la aplicación de una llamada si se agrega un interceptor que valida el client ID en el flujo (OAuth o Client ID Validation). Además, la app debe asociarse a la API a través de un plan.

Consulte las preguntas más frecuentes sobre los flujos de API (y sobre todo más) en nuestra sección de FAQs de la API Platform.
Thanks for your feedback!
EDIT

Share your suggestions with us!
Click here and then [+ Submit idea]