Antipadrão: chamar um proxy dentro de um proxy usando código personalizado ou como um destino

Esta é a documentação da Apigee e da Apigee híbrida.
Confira a documentação da Apigee Edge.

A Apigee permite invocar um proxy de API a partir de outro proxy de API. Esse recurso é útil especialmente se você tiver um proxy de API que contenha código reutilizável que possa ser usado por outros proxies de API.

Antipadrão

Invocar um proxy de API de outro usando HTTPTargetConnection no endpoint de destino ou código de JavaScript personalizado resulta em outro salto de rede.

Chamar o proxy 2 do proxy 1 usando HTTPTargetConnection

O exemplo de código a seguir chama o Proxy 2 do Proxy 1 usando HTTPTargetConnection:

<!-- /antipatterns/examples/2-1.xml -->
<HTTPTargetConnection>
  <URL>https://api-test.example.com/proxy2</URL>
</HTTPTargetConnection>

Chamar o proxy 2 do proxy 1 a partir do código JavaScript

A próxima amostra de código invoca o proxy 2 pelo proxy 1 usando JavaScript:

<!-- /antipatterns/examples/2-2.xml -->
var response = httpClient.send('https://api-test.example.com/proxy2);
response.waitForComplete();

Fluxo de códigos

Para entender por que isso tem uma desvantagem inerente, precisamos entender o trajeto que uma solicitação leva conforme ilustrado no diagrama abaixo:

1) O cliente faz solicitações ao proxy 1, 2) a solicitação do proxy 1 ao Proxy 2 leva ao salto de rede,
            3) a solicitação do proxy 2 à segmentação.
Figura 1: fluxo de código

Conforme mostrado no diagrama, uma solicitação passa por vários componentes distribuídos, incluindo o roteador e o Processador de mensagens.

Nas amostras de código acima, invocar o proxy 2 pelo proxy 1 significa que a solicitação precisa ser encaminhada pela rota tradicional (ou seja, roteador > MP) no tempo de execução. Isso seria complicado invocar uma API de um cliente, fazendo vários saltos de rede que adicionam à latência. Esses saltos não são necessários, uma vez que a solicitação do proxy 1 já alcançou o MP.

Impacto

Invocar um proxy de API de outro proxy de API gera saltos de rede desnecessários, que é a solicitação que precisa ser passada de um processador de mensagens para outro.

Prática recomendada

  • Use o recurso de cadeia de proxy para invocar um Proxy de API de outro. O encadeamento de proxy é mais eficiente, porque usa conexão local para fazer referência ao endpoint de destino (outro proxy da API).

    O exemplo de código mostra o encadeamento de proxy usando LocalTargetConnection na definição do endpoint:

    <!-- /antipatterns/examples/2-3.xml -->
    <LocalTargetConnection>
      <APIProxy>proxy2</APIProxy>
      <ProxyEndpoint>default</ProxyEndpoint>
    </LocalTargetConnection>
    

    O proxy da API invocado é executado no mesmo processador de mensagens. Consequentemente, ele evita o salto de rede conforme mostrado na figura a seguir:

    1) O cliente faz uma solicitação ao proxy 1, 2) uma solicitação de proxy 1 para um proxy 2 feita
            por chamada psuedo local; 3) solicitação do proxy 2 para destino.
    Figura 2: fluxo de código com encadeamento de proxy

Leitura adicional