Antimodèle : Appeler un proxy dans un proxy à l'aide d'un code personnalisé ou en tant que cible

<ph type="x-smartling-placeholder"></ph> Vous consultez la documentation Apigee Edge.
Accédez à la page Documentation sur 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, vous disposez d'un proxy d'API qui contient du code réutilisable qui peut ê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 :

  

Documentation complémentaire

• Chaînage de proxys