Saltar al contenido

Tipos de API Manager

Descripción General

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

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

Para obtener más información sobre la arquitectura del sistema y la seguridad de Jitterbit, consulte Informe 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. A continuación, 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 Harmony Agents (ya sea Grupos de Agentes en 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 Nube y una Pasarela de API en Nube:

diagrama cutsom api cloud deployment pp

  1. Un consumidor de API realiza una llamada a la API Personalizada ubicada en Pasarela de API en Nube.

  2. La solicitud de API Personalizada se enruta a través de Pasarela de API en Nube al servicio de mensajería, que enruta las solicitudes de grupos de Agente.

  3. Un Agente en Nube recibe la solicitud del servicio de mensajería.

  4. El Agente en Nube hace referencia a la operación de la API Personalizada especificada durante la Configuración de la API Personalizada y activa la operación implementada.

  5. La operación responde con una carga útil de 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 en Nube de vuelta al consumidor de la API.

    Nota

    A menos que la operación desencadenada por la llamada a la 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 depurar está habilitado durante 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 una operación de entidad API de Design Studio para el consumo. La operación de la entidad API primero debe crearse e desplegarse en Harmony. A continuación, se hace referencia a la operación de la entidad API existente durante la configuración del Servicio OData y un consumidor API la llama y la consume. Los servicios OData se enrutan a través de los agentes de Harmony (ya sea Grupos de Agentes en 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 Pasarela de API Privada:

diagrama del servicio de odata en las instalaciones de despliegue pp

  1. Un consumidor de API realiza una llamada al Servicio OData ubicado en Pasarela de API Privada.

  2. La solicitud del Servicio OData se enruta a través de Pasarela de API Privada.

  3. El servicio de mensajería recibe la solicitud, que enruta las solicitudes para los grupos de Agente.

  4. El Agente Privado recibe la solicitud del servicio de mensajería.

  5. El Agente Privado hace referencia a la operación de la entidad API del Servicio OData en Harmony y activa la operación de la 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 Pasarela de API Privada de regreso al consumidor de API.

    Nota

    A menos que la operación desencadenada por la llamada a la 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 depurar está habilitado durante Configuración del Servicio OData.

  8. Los registros en el Agente Privado se pueden sincronizar opcionalmente con la base de datos de registros de transacciones dentro de Harmony.

Para obtener información sobre la configuración de 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 el consumo, las APIs de proxy se utilizan con una API de externo existente y no se enrutan a través de los agentes de Harmony. La API que se utiliza como proxy debe ser accesible para la puerta de enlace que procesa la API, ya sea la Pasarela de API en Nube o una Pasarela de API Privada:

  • Pasarela de API en Nube: si utiliza la puerta de enlace de 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 convertir en proxy no puede estar detrás de un firewall. Para lista de permisos en la lista blanca las direcciones IP de la Pasarela de API en Nube para permitir que la puerta de enlace acceda a la API que se utiliza como proxy, consulte Información de la lista blanca y navegue hasta https://services.jitterbit para su región.

  • Pasarela de API Privada: Si usa una Pasarela de API Privada, la API existente debe ser accesible por Pasarela de API Privada.

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

diagrama proxy api nube despliegue pp

  1. Un consumidor de API realiza una llamada a la API de proxy ubicada en Pasarela de API en Nube.

  2. La llamada a la API del proxy se enruta a través de Pasarela de API en Nube y se envía a la API de externo que se utiliza como proxy.

  3. La carga útil de la API se enruta a través de Pasarela de API en Nube de regreso al consumidor de la API.

  4. La API de externo responde con una carga útil de API que se enruta a Pasarela de API en Nube de regreso al consumidor de API.

  5. La información de 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 depurar está habilitado durante Configuración de la proxy de API.

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