Antipatrón: invoca un proxy dentro de un proxy mediante un código personalizado o como un objetivo

Estás viendo la documentación de Apigee X.
Consulta la documentación de Apigee Edge.

Apigee te permite invocar un proxy de API desde otro proxy de API. Esta función es útil en especial si tienes un proxy de API que contiene código reutilizable que pueden usar otros proxies de API.

Antipatrón

Invocar un proxy de API desde otro mediante HTTPTargetConnection en el extremo objetivo o el código JavaScript personalizado genera un salto de red adicional.

Invoca el proxy 2 del proxy 1 con HTTPTargetConnection

El siguiente ejemplo de código invoca el proxy 2 desde el proxy 1 mediante HTTPTargetConnection:

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

Invoca el proxy 2 desde el proxy 1 del código JavaScript

El siguiente ejemplo de código invoca el proxy 2 desde el proxy 1 mediante JavaScript:

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

Flujo de código

Para comprender por qué existe una desventaja inherente, debemos comprender la ruta que realiza una solicitud, como se ilustra en el siguiente diagrama:

1) El cliente realiza una solicitud al proxy 1, 2) la solicitud del proxy 1 al proxy 2 incurre en el salto de red, 3) Solicitud del proxy 2 al objetivo.
Figura 1: Flujo de código

Como se muestra en el diagrama, una solicitud recorre varios componentes distribuidos, incluidos el router y el procesador de mensajes.

En los ejemplos de código anteriores, invocar el proxy 2 desde el proxy 1 significa que la solicitud debe enrutarse a través de la ruta tradicional (Router > MP) en el entorno de ejecución. Esto sería similar a la invocación de una API de un cliente y, así, hacer saltos de red múltiples que se agregan a la latencia. Estos saltos no son necesarios si consideramos que la solicitud de proxy 1 ya llegó al MP.

Impacto

La invocación de un proxy de API desde otro proxy de API genera saltos de red innecesarios, es decir que la solicitud debe pasar de un procesador de mensajes a otro procesador de mensajes.

Práctica recomendada

  • Usa la característica de encadenamiento de proxy para invocar un proxy de API desde otro. El encadenamiento de proxy es más eficiente porque usa una conexión local para hacer referencia al extremo de destino (otro proxy de API).

    En la muestra de código, se muestra el encadenamiento de proxy con LocalTargetConnection en tu definición de extremo:

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

    El proxy de API invocado se ejecuta dentro del mismo procesador de mensajes. Como resultado, se evita el salto de red como se muestra en la siguiente figura:

    1) El cliente realiza una solicitud al proxy 1, 2) Solicitud del proxy 1 al proxy 2 mediante una llamada psuedo local, 3) Solicitud del proxy 2 al destino.
    Figura 2: Flujo de código con encadenamiento de proxy

Lecturas adicionales