Tipos de API del API Manager¶

Descripción General¶

Dentro de API Manager, puedes crear y publicar tres tipos de APIs:

• API Personalizada
• Servicio OData
• proxy de API

Cada tipo de API interactúa con Harmony de forma única dentro de la arquitectura del sistema, como se describe a continuación.

Para obtener más información sobre la seguridad y la arquitectura del sistema de Jitterbit, consulte el documento técnico sobre arquitectura y seguridad de Jitterbit.

API Personalizada¶

Las APIs personalizadas exponen una operación de Harmony para su consumo. Primero se debe crear e desplegar una operación en Harmony y puede ser cualquier Cloud Studio o Design Studio operación. Luego se hace referencia a la operación existente durante la configuración de la API personalizada y un consumidor de API la llama y la consume. Las APIs personalizadas se enrutan a través de agentes de Harmony (ya sea grupos de agentes en la nube o agentes privados).

Este diagrama muestra cómo se comporta una API personalizada en la arquitectura del sistema cuando se implementa con un agente en la nube y una puerta de enlace API en la nube:

1. Un consumidor de API realiza una llamada a la API personalizada ubicada en la puerta de enlace de API en la nube.

2. La solicitud de API personalizada se enruta a través de la puerta de enlace de API en la nube al servicio de mensajería, que enruta las solicitudes para grupos de agentes.

3. Un agente de la nube recibe la solicitud del servicio de mensajería.

4. El agente de la nube hace referencia a la operación de API personalizada especificada durante la configuración de API personalizada y desencadena la operación desplegada.

5. La operación responde con una carga útil API consistente con el tipo de respuesta seleccionado durante la configuración de API personalizada.

6. La carga útil de la API se enruta desde el agente de la nube al consumidor de la API.

   Nota

   A menos que la operación que se activa mediante la llamada API utilice Almacenamiento temporal, la carga útil de la API permanecerá en el agente solo durante dos días.

7. La información del estado del tiempo de ejecución y los registros de las operaciones en ejecución se envían a la base de datos de registros de transacciones.

   Nota

   Los datos del consumidor no se almacenan en la base de datos de registros de transacciones a menos que modo de depurar está habilitado durante la configuración de API personalizada.

Para obtener información sobre cómo configurar una API personalizada, consulte Configuración de API Personalizada.

Servicio OData¶

Los servicios OData exponen un Design Studio operación de entidad API para consumo. Primero se debe crear e desplegar la operación de entidad API en Harmony. Luego se hace referencia a la operación de entidad API existente durante la configuración del servicio OData y un consumidor de API la llama y la consume. Los servicios OData se enrutan a través de agentes de Harmony (ya sea grupos de agentes en la nube o agentes privados).

Este diagrama muestra cómo se comporta un servicio OData en la arquitectura del sistema cuando se implementa localmente con un agente privado y una puerta de enlace API privada:

1. Un consumidor de API realiza una llamada al servicio OData ubicado en la puerta de enlace de API privada.

2. La solicitud del servicio OData se enruta a través de la puerta de enlace API privada.

3. La solicitud es recibida por el servicio de mensajería, que enruta las solicitudes para grupos de agentes.

4. El agente privado recibe la solicitud del servicio de mensajería.

5. El agente privado hace referencia a la operación de entidad API del servicio OData en Harmony y activa la operación de entidad implementada.

6. La operación responde con una carga útil de API que se enruta desde el agente privado a través de la puerta de enlace de API privada de regreso al consumidor de API.

   Nota

   A menos que la operación que se activa mediante la llamada API utilice Almacenamiento temporal, la carga útil de la API permanecerá en el agente solo durante dos días.

7. La información del estado del tiempo de ejecución y los registros de las operaciones en ejecución se envían a la base de datos de registros de transacciones en el agente privado.

   Nota

   Los datos del consumidor no se almacenan en la base de datos de registros de transacciones a menos que modo de depurar está habilitado durante la configuración del servicio OData.

8. Los registros del agente privado se pueden sincronizar opcionalmente con la base de datos de registros de transacciones dentro de Harmony.

Para obtener información sobre cómo configurar un servicio OData, consulte Configuración del servicio OData.

Proxy de API¶

A diferencia de APIs personalizadas o servicios OData, que exponen una operación de Harmony para su consumo, las APIs de proxy se utilizan con una API de externo existente y no se enrutan a través de agentes de Harmony. La API a la que se aplica el proxy debe ser accesible para la puerta de enlace que procesa la API, ya sea la puerta de enlace de API en la nube o una puerta de enlace de API privada:

• Puerta de enlace API en la nube: Si se utiliza la puerta de enlace API que Jitterbit aloja en Harmony, la API existente debe ser accesible públicamente, incluso si está protegida. Es decir, la API que está intentando utilizar como proxy no puede estar detrás de un firewall. Para lista de permisos de direcciones IP de la puerta de enlace API en la nube para permitir el acceso de la puerta de enlace a la API que se está representando, consulte Información de la lista de permitidos y navegar a https://services.jitterbit para su región.

• Puerta de enlace API privada: Si utiliza una puerta de enlace API privada, la API existente debe ser accesible a través de la puerta de enlace API privada.

Este diagrama muestra cómo se comporta una API de proxy en la arquitectura del sistema cuando la procesa la puerta de enlace de API en la nube:

1. Un consumidor de API realiza una llamada a la API de proxy ubicada en la puerta de enlace de API en la nube.

2. La llamada a la API de proxy se enruta a través de la puerta de enlace de API en la nube y se envía a la API de externo que se está representando.

3. La carga útil de la API se enruta a través de la puerta de enlace de la API en la nube de regreso al consumidor de la API.

4. La API de externo responde con una carga útil de API que se enruta a la puerta de enlace de API en la nube y regresa al consumidor de API.

5. La información del estado del tiempo de ejecución se envía a la base de datos de registros de transacciones.

   Nota

   Los datos del consumidor no se almacenan en la base de datos de registros de transacciones a menos que modo de depurar está habilitado durante la configuración de API de proxy.

Para obtener información sobre cómo configurar una API de proxy, consulte Configuración de proxy de API.