Edge lets you invoke one API Proxy from another API Proxy. This feature is useful especially if you have an API Proxy that contains reusable code that can be used by other API Proxies.
Invoke Proxy 2 from Proxy 1 using HTTPTargetConnection
The following code sample invokes Proxy 2 from Proxy 1 using HTTPTargetConnection:
<!-- /antipatterns/examples/2-1.xml --> <HTTPTargetConnection> <URL>http://myorg-test.apigee.net/proxy2</URL> </HTTPTargetConnection>
<!-- /antipatterns/examples/2-2.xml --> var response = httpClient.send('http://myorg-test.apigee.net/proxy2); response.waitForComplete();
To understand why this has an inherent disadvantage, we need to understand the route a request takes as illustrated by the diagram below:
As depicted in the diagram, a request traverses multiple distributed components, including the Router and the Message Processor.
In the code samples above, invoking Proxy 2 from Proxy 1 means that the request has to be routed through the traditional route (i.e Router > MP) at runtime. This would be akin to invoking an API from a client thereby making multiple network hops that add to the latency. These hops are unnecessary considering that Proxy 1 request has already "reached" the MP.
Invoking one API Proxy from another API Proxy incurs unnecessary network hops, that is the request has to be passed on from one Message Processor to another Message Processor.
- Use the proxy chaining
feature for invoking one API Proxy from another. Proxy chaining is more
efficient as it uses local connection to reference the target endpoint (another API Proxy).
The code sample shows proxy chaining using LocalTargetConnection in your endpoint definition:
<!-- /antipatterns/examples/2-3.xml --> <LocalTargetConnection> <APIProxy>proxy2</APIProxy> <ProxyEndpoint>default</ProxyEndpoint> </LocalTargetConnection>
The invoked API Proxy gets executed within the same Message Processor; as a result, it avoids the network hop as shown in the following figure: