Estás consultando la documentación de Apigee Edge.
Consulta la
documentación de Apigee X. Información
Edge 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 utilizar otros proxies de API.
Antipatrón
Si se invoca un proxy de API desde otro, ya sea mediante HTTPTargetConnection en el extremo de destino o un código JavaScript personalizado, se generará un salto de red adicional.
Invoca el proxy 2 desde el proxy 1 mediante HTTPTargetConnection
En la siguiente muestra de código, se invoca al proxy 2 del proxy 1 mediante HTTPTargetConnection:
<!-- /antipatterns/examples/2-1.xml --> <HTTPTargetConnection> <URL>http://myorg-test.apigee.net/proxy2</URL> </HTTPTargetConnection>
Invoca el proxy 2 desde el proxy 1 desde el código JavaScript.
La siguiente muestra de código invoca el proxy 2 del proxy 1 con JavaScript:
<!-- /antipatterns/examples/2-2.xml -->
var response = httpClient.send('http://myorg-test.apigee.net/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:
Como se muestra en el diagrama, una solicitud recorre varios componentes distribuidos, incluidos el router y el procesador de mensajes.
En las muestras 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 (es decir, Router > MP) en el entorno de ejecución. Esto sería similar a invocar una API desde un cliente, por lo tanto, realizar varios saltos de red que aumentan la latencia. Estos saltos no son necesarios si se tiene en cuenta que la solicitud del proxy 1 ya "alcanzó" al MP.
Impacto
Invocar un proxy de API desde otro genera saltos de red innecesarios, es decir, la solicitud debe pasarse de un Message Processor a otro Message Processor.
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 indica el encadenamiento de proxy con LocalTargetConnection en la definición de tu 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:
Figura 2: Flujo de código con encadenamiento de proxy