Antipattern: invocar um proxy num proxy através de código personalizado ou como alvo

Está a ver a documentação do Apigee e do Apigee Hybrid.
Veja a documentação do Apigee Edge.

O Apigee permite-lhe invocar um proxy de API a partir de outro proxy de API. Esta funcionalidade é especialmente útil se tiver um proxy de API que contenha código reutilizável que possa ser usado por outros proxies de API.

Antipattern

Invocar um proxy de API a partir de outro através de HTTPTargetConnection no ponto final de destino ou de código JavaScript personalizado resulta num salto de rede adicional.

Invocar o proxy 2 a partir do proxy 1 através de HTTPTargetConnection

O seguinte exemplo de código invoca o proxy 2 a partir do proxy 1 através de HTTPTargetConnection:

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

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

O exemplo de código seguinte invoca o proxy 2 a partir do proxy 1 através de JavaScript:

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

Fluxo de código

Para compreender por que motivo isto tem uma desvantagem inerente, temos de compreender o caminho que um pedido percorre, conforme ilustrado no diagrama abaixo:

Figura 1: fluxo de código

Conforme representado no diagrama, um pedido atravessa vários componentes distribuídos, incluindo o router e o processador de mensagens.

Nos exemplos de código acima, invocar o proxy 2 a partir do proxy 1 significa que o pedido tem de ser encaminhado através da rota tradicional (Router > MP) no tempo de execução. Isto seria semelhante a invocar uma API a partir de um cliente, fazendo assim vários saltos de rede que aumentam a latência. Estes saltos são desnecessários, tendo em conta que o pedido do proxy 1 já chegou ao MP.

Impacto

A invocação de um proxy de API a partir de outro proxy de API incorre em saltos de rede desnecessários, ou seja, o pedido tem de ser transmitido de um processador de mensagens para outro.

Prática recomendada

• Use a funcionalidade de encadeamento de proxies para invocar um proxy de API a partir de outro. O encadeamento de proxies é mais eficiente, uma vez que usa a ligação local para referenciar o ponto final de destino (outro proxy de API).

  O exemplo de código mostra o encadeamento de proxies através de LocalTargetConnection na definição do seu ponto final:

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

  O proxy de API invocado é executado no mesmo processador de mensagens. Como resultado, evita o salto de rede, conforme mostrado na figura seguinte:

  

  Figura 2: fluxo de código com encadeamento de proxy

Leitura complementar

• Encadeamento de proxies