Encadeamento de proxies de API

Esta página aplica-se ao Apigee e ao Apigee Hybrid.

Veja a documentação do Apigee Edge.

Pode especificar que um proxy é o ponto final de destino de outro, ligando efetivamente os dois proxies numa cadeia de proxies. A encadeamento de proxies desta forma pode ajudar a evitar um salto de rede e, por isso, melhorar o desempenho geral.

Nota: cada proxy na cadeia é faturado como uma chamada e conta como uma chamada para os limites.

Nota: o encadeamento de proxies oferece uma forma de reutilizar proxies. Para outra forma de desenvolver componentes expressamente concebidos para serem reutilizados, certifique-se de que consulta os fluxos partilhados reutilizáveis.

Com a encadeamento de proxies, especifica que um proxy é o ponto final de destino local do outro. Em vez de usar o elemento HTTPTargetConnection para fazer uma chamada ao segundo proxy, usa o elemento LocalTargetConnection.

<LocalTargetConnection>
    <APIProxy>myproxy2</APIProxy>
    <ProxyEndpoint>default</ProxyEndpoint>
</LocalTargetConnection>

A encadeamento de proxies pode ser útil quando tem um proxy que oferece alguma funcionalidade discreta de baixo nível que outros proxies vão consumir. Por exemplo, um proxy que exponha operações de criação/leitura/atualização/eliminação com um arquivo de dados de back-end pode ser o proxy de destino para vários outros proxies que expõem os dados aos clientes.

Nota: os proxies que quer ligar desta forma têm de estar na mesma organização e ambiente. Quando o proxy ao qual está a estabelecer ligação está fora deste âmbito, considere estabelecer ligação ao mesmo como um recurso externo através do elemento HTTPTargetConnection (conforme descrito na referência de configuração do proxy da API).

Nota: este vídeo foi gravado com uma versão anterior da IU do Apigee. No entanto, os conceitos continuam válidos.

Vídeo: veja um breve vídeo para saber mais sobre o encadeamento de proxies de API.

Como funciona o encadeamento de proxies

O encadeamento de proxies usa uma ligação local para minimizar a sobrecarga da rede quando chama um proxy de outro. Esta ligação local é mais eficiente porque ignora as funcionalidades de rede, como balanceadores de carga, routers e processadores de mensagens.

A imagem seguinte ilustra a diferença entre associar proxies com HTTPTargetConnection e LocalTargetConnection (encadeamento de proxies):

Liga proxies especificando que um é um ponto final de destino local do outro. Para a configuração no diagrama acima (chamada de proxy para proxy com encadeamento de proxies), especificaria que ProxyB (/proxyB) é um ponto final de destino local de ProxyA (/proxyA). Isto faz com que os pedidos que chegam ao ProxyA sejam encaminhados para o ProxyB.

Pode criar uma ligação local entre proxies de duas formas:

• Especificando o nome do proxy de destino e um nome de ProxyEndpoint
• Especificando um caminho para o ponto final do proxy de destino

Associa proxies de destino numa configuração TargetEndpoint, usando um elemento LocalTargetConnection, conforme descrito abaixo.

Aviso: quando encadeia proxies de API, tenha cuidado para evitar chamadas recursivas de ciclo infinito de volta ao mesmo proxy de API, o que pode resultar numa sobrecarga do sistema.

Nota: se estiver a usar o Apigee hybrid v1.14 ou mais recente e a sua organização tiver o direito de usar a funcionalidade Enhanced per-environment proxy limits, tem de definir a propriedade enhanceProxyLimits como true no ficheiro overrides.yaml para usar o encadeamento de proxies.

Associar proxies por nome do proxy

Pode especificar o proxy de destino por nome. Pode considerar que esta opção é mais útil quando cria a associação desde o início e desenvolve os proxies em conjunto. Se não souber o nome (ou o nome pode mudar), considere estabelecer ligação ao caminho do ponto final do proxy de destino, conforme descrito abaixo.

Quando se liga a um proxy de destino por nome, especifica o nome do proxy e o nome do respetivo ProxyEndpoint.

O exemplo seguinte especifica um proxy de destino denominado data-manager, juntamente com o nome ProxyEndpoint exposto por data-manager. Para informações de referência, consulte o artigo Referência de configuração do proxy da API.

Os elementos <APIProxy> e <ProxyEndpoint> suportam a funcionalidade de substituição de strings dinâmicas denominada modelos de mensagens.

Importante: se implementar o encadeamento de proxies através do nome do proxy, o segundo proxy não apresenta resultados em Debug, mesmo quando o chama para ele. Em alternativa, use a Encadeamento de proxies por caminho se precisar de usar a depuração no segundo proxy.

<TargetEndpoint name="datamanager">
    <PreFlow name="PreFlow">
        <!-- PreFlow policies -->
    </PreFlow>
    <PostFlow name="PostFlow">
        <!-- PostFlow policies -->
    </PostFlow>
    <LocalTargetConnection>
        <APIProxy>data-manager</APIProxy>
        <ProxyEndpoint>default</ProxyEndpoint>
    </LocalTargetConnection>
</TargetEndpoint>

Associar proxies por caminho

Pode especificar o proxy de destino pelo respetivo caminho do ponto final. Pode querer fazê-lo desta forma quando não souber o nome do proxy ou quando o nome puder mudar.

Se o seu proxy for simplesmente o consumidor do proxy de destino, por exemplo, quando não está a desenvolver ambos, o caminho pode ser a forma mais fiável de estabelecer ligação. Por exemplo, se o proxy ao qual se está a ligar for desenvolvido e mantido por outra equipa, é recomendável estabelecer ligação através de um caminho de ponto final fiável.

O exemplo seguinte especifica um proxy de destino em /v1/streetcarts/foodcarts/data-manager, onde se assume que o anfitrião é o mesmo que o proxy atual. Para informações de referência, consulte o artigo Referência de configuração do proxy de API.

<TargetEndpoint name="datamanager">
    <PreFlow name="PreFlow">
        <!-- PreFlow policies -->
    </PreFlow>
    <PostFlow name="PostFlow">
        <!-- PostFlow policies -->
    </PostFlow>
    <LocalTargetConnection>
        <Path>/v1/streetcarts/foodcarts/data-manager</Path>
    </LocalTargetConnection>
</TargetEndpoint>

O elemento <Path> em <LocalTargetConnection> pode ser uma string ou pode usar um modelo de mensagem para atribuir um valor dinamicamente.

Associar proxies através da IU do Apigee

Também pode ligar proxies, por nome ou caminho do proxy, através da IU do Apigee. No exemplo seguinte, existem dois proxies, ProxyA e ProxyB, e quer que o ProxyB seja um ponto final de destino do ProxyA. Para associar os proxies por nome do proxy, siga estes passos:

1. Aceda à lista de proxies.

Apigee na Cloud Console

Na Google Cloud consola, aceda à página Desenvolvimento de proxy > Proxies de API.

Aceda aos proxies de API

IU do Apigee Classic

1. Inicie sessão na IU do Apigee.
2. Selecione Desenvolver > Proxies no painel do lado esquerdo.
2. Na lista de proxies, selecione ProxyA.
3. Clique no separador Desenvolver.
4. No painel Código, substitua a secção <TargetEndpoint> do XML pelo seguinte:

   <TargetEndpoint>
     <LocalTargetConnection>
       <APIProxy>ProxyB</APIProxy>
       <ProxyEndpoint>default</ProxyEndpoint>
     </LocalTargetConnection>
   </TargetEndpoint>

5. Clique em Guardar.

Proxies encadeados, produtos de API e segurança

O encadeamento de proxies é mais adequado para casos em que ambos os proxies estão no mesmo produto de API. Por predefinição, ambos estão disponíveis para os clientes. Atualmente, o Apigee não suporta a união do segundo proxy num produto API separado ao qual os clientes não devem ter acesso.

Se o segundo proxy tiver de estar protegido contra pedidos diretos do cliente, pondere adicionar lógica para que o segundo proxy examine o endereço IP do cliente. No caso de uma chamada feita com encadeamento, o endereço IP é local. O seu código pode validar se é local antes de permitir que o processamento continue. Consulte a política AccessControl para saber uma forma de o fazer.