Vous consultez la documentation d'Apigee Edge.
Consultez la
documentation Apigee X. en savoir plus
Edge vous permet d'appeler un proxy d'API à partir d'un autre proxy d'API. Cette fonctionnalité est utile surtout si vous disposez d'un proxy d'API contenant du code réutilisable pouvant être utilisé par d'autres proxys d'API.
Antimodèle
L'appel d'un proxy d'API à partir d'un autre proxy via le protocole HTTPTargetConnection dans le point de terminaison cible ou le code JavaScript personnalisé entraîne un saut de réseau supplémentaire.
Appeler le proxy 2 à partir du proxy 1 via HTTPTargetConnection
L'exemple de code suivant appelle le proxy 2 à partir du proxy 1 via HTTPTargetConnection :
<!-- /antipatterns/examples/2-1.xml --> <HTTPTargetConnection> <URL>http://myorg-test.apigee.net/proxy2</URL> </HTTPTargetConnection>
Appeler le proxy 2 à partir du proxy 1 à partir du code JavaScript
L'exemple de code suivant appelle le proxy 2 à partir du proxy 1 à l'aide de JavaScript :
<!-- /antipatterns/examples/2-2.xml -->
var response = httpClient.send('http://myorg-test.apigee.net/proxy2);
response.waitForComplete();
Flux de code
Pour comprendre pourquoi cela présente un inconvénient inhérent, nous devons comprendre la route empruntée par une requête, comme l'illustre le diagramme ci-dessous :
Comme le montre le diagramme, une requête parcourt plusieurs composants distribués, par exemple le routeur et le processeur de messages.
Dans les exemples de code ci-dessus, l'appel du proxy 2 à partir du proxy 1 signifie que la requête doit être acheminée via la route traditionnelle (routeur > processeur de messages) au moment de l'exécution. Cela ressemblerait à un appel vers un API à partir d'un client à partir d'un client, entraînant ainsi l'ajout de plusieurs sauts de réseau à la latence. Ces sauts sont inutiles étant donné que la requête du proxy 1 a déjà "atteint" le processeur de messages.
Impact
L'appel d'un proxy d'API à partir d'un autre proxy d'API entraîne des sauts de réseau inutiles, c'est-à-dire que la requête doit être transmise d'un processeur de messages à un autre processeur de messages.
Bonne pratique
- Utilisez la fonctionnalité de chaînage de proxys pour appeler un proxy d'API à partir d'un autre. Le chaînage de proxys est plus efficace, car il utilise la connexion locale pour référencer le point de terminaison cible (un autre proxy d'API).
L'exemple de code montre comment créer des chaînes de proxys à l'aide de LocalTargetConnection dans votre définition de point de terminaison :
<!-- /antipatterns/examples/2-3.xml --> <LocalTargetConnection> <APIProxy>proxy2</APIProxy> <ProxyEndpoint>default</ProxyEndpoint> </LocalTargetConnection>
Le proxy d'API appelé est exécuté dans le même processeur de messages, ce qui évite le saut de réseau, comme illustré dans la figure suivante :
Figure 2: Flux de code avec chaîne de proxy