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.](https://cloud.google.com/static/apigee/docs/api-platform/images/antipatterns/proxies-requests.png?authuser=6&hl=pt-br)
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:
Figura 2: fluxo de código com encadeamento de proxy