Ir para o conteúdo

Jitterbit gateway de API privado

Introdução

Um gateway de API privado, hospedado em uma rede privada, lida com esses recursos de segurança e tarefas envolvidas na aceitação e processamento de chamadas da API do API Manager:

  • Gerenciamento de tráfego.
  • Autorização e controle de acesso.
  • Limitação de taxa.
  • Processamento de payload da API.

Você pode instalar e executar um gateway de API privado em Linux, ou executar um como um container Docker baseado em Linux.

Um gateway de API privado é um gateway local para processar APIs diretamente de seus próprios servidores. Os recursos de segurança do API Manager são configurados no nível da API ou no nível do perfil de segurança e são armazenados em cache no gateway de API privado, que são então referenciados durante a execução da API, conforme descrito abaixo.

Arquitetura do sistema do gateway de API privado

Usar um gateway de API privado oferece essas vantagens adicionais em relação ao gateway de API em nuvem:

  • Rede Interna: O gateway de API privado e seus agentes podem ser restritos exclusivamente a uma rede interna atrás de um firewall e não ser acessíveis a partir da Internet.

    Nota

    Se a instalação do seu gateway de API privado estiver atrás de um firewall dentro da sua rede, você deve permitir os serviços necessários do Jitterbit.

  • Segurança do Payload: Os payloads de resposta da API nunca passam pelos sistemas do Jitterbit.

  • Controle: Você tem controle sobre o ambiente de hardware e software do gateway de API privado, garantindo que atenda aos padrões da sua empresa.
  • Nome de Domínio: A URL base do endpoint da API pode ser configurada para ser um subdomínio de um nome de domínio que você controla, em vez de um subdomínio da região Harmony (jitterbit.cc, jitterbit.eu ou jitterbit.net). Uma alternativa ao uso de um gateway de API privado para controlar o nome de domínio é usar uma ferramenta de terceiros, como Cloudflare ou um proxy DNS, para direcionar um nome de domínio personalizado para a URL base.

Este diagrama exibe a arquitetura do sistema de uma API personalizada implantada localmente com um agente privado e um gateway de API privado:

attachment

  1. Um consumidor de API faz uma chamada para a API localizada no gateway de API privado.

  2. O gateway de API privado referencia os perfis de segurança em cache (se aplicável) e os metadados da API para realizar tarefas de autenticação e controle de acesso. Se o acesso à API for negado, o gateway de API privado retornará uma resposta HTTP apropriada e um status para o consumidor de API. Se o acesso à API for concedido, a solicitação da API é roteada para o serviço de mensagens, que roteia solicitações para grupos de agentes.

  3. O agente privado recebe a solicitação do serviço de mensagens.

  4. O agente privado referencia a operação da API especificada durante a configuração da API personalizada e aciona a operação implantada.

  5. A operação responde com uma carga útil da API consistente com o tipo de resposta selecionado durante a configuração da API personalizada.

  6. A carga útil da resposta da API é roteada do agente privado de volta para o gateway de API privado, que extrai a carga útil da API e define a resposta HTTP final e o status. A resposta HTTP e o status são enviados ao consumidor de API.

    Nota

    A menos que a operação acionada pela chamada da API esteja usando Armazenamento Temporário, a carga útil da resposta da API permanecerá no agente por um máximo de dois dias. A carga útil da resposta da API permanecerá no gateway de API privado por no máximo o tempo limite do gateway de API de 15 segundos.

    Cuidado

    Em ambientes de múltiplos gateways atrás de um balanceador de carga de aplicativo (ALB) como o AWS ALB, se um gateway não tiver a carga útil solicitada, uma solicitação proxy será criada para o gateway que a possui para garantir a recuperação da carga útil.

O roteamento bem-sucedido de payloads pode exigir configuração adicional dependendo do seu ambiente de múltiplos gateways.

  1. Informações de status de runtime e logs de operações em execução são enviadas para o banco de dados de logs de transações.

    Nota

    Os dados do consumidor não são armazenados no banco de dados de logs de transações, a menos que o modo de depuração esteja habilitado durante a configuração da API personalizada.