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

Vous consultez la documentation d'Apigee et d'Apigee hybrid.
Consultez la documentation d'Apigee Edge.

Apigee vous permet d'appeler un proxy d'API à partir d'un autre proxy d'API. Cette fonctionnalité est particulièrement utile si vous disposez d'un proxy d'API contenant 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 à l'aide de `HTTPTargetConnection`

L'exemple de code suivant appelle le proxy 2 à partir du proxy 1 via HTTPTargetConnection :

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

Appeler le proxy 2 à partir du proxy 1 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('https://api-test.example.com/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 :

1) Le client envoie une requête au proxy 1, 2) La requête du proxy 1 au proxy 2 entraîne un saut de réseau, 3) Requête du proxy 2 à cibler. — **Figure 1** : Flux de code

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 ne sont pas nécessaires si vous considérez 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 :
```

<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înage de proxys

Documentation complémentaire

Chaînage de proxys