Associer des proxys d'API en chaîne

Cette page s'applique à Apigee et à Apigee hybrid.

Consultez la documentation d'Apigee Edge.

Vous pouvez spécifier qu'un proxy est le point de terminaison cible d'un autre proxy en associant efficacement les deux proxys en chaîne. L'association de proxys en chaîne permet d'éviter les sauts de réseau et donc d'améliorer les performances globales.

Remarque : Chaque proxy de la chaîne est facturé comme un appel et est comptabilisé comme un appel dans les limites.

Remarque : L'association de proxys en chaîne permet de réutiliser les proxys. En revanche, si vous développez des composants spécialement conçus pour être réutilisés, veillez à consulter l'article Flux partagés réutilisables.

Avec l'association de proxys en chaîne, vous spécifiez qu'un proxy est le point de terminaison cible local de l'autre. Plutôt que d'utiliser l'élément HTTPTargetConnection pour appeler le deuxième proxy, vous utilisez l'élément LocalTargetConnection.

<LocalTargetConnection>
    <APIProxy>myproxy2</APIProxy>
    <ProxyEndpoint>default</ProxyEndpoint>
</LocalTargetConnection>

L'association de proxys en chaîne peut être utile lorsque vous disposez d'un proxy qui propose une fonctionnalité discrète de bas niveau que les autres proxys utilisent. Par exemple, un proxy qui expose les opérations de création/lecture/mise à jour/suppression avec un datastore backend peut être le proxy cible pour plusieurs autres proxys qui exposent les données aux clients.

Remarque : Les proxys que vous souhaitez connecter de cette manière doivent appartenir à la même organisation et au même environnement. Lorsque le proxy auquel vous vous connectez se situe en dehors de ce champ d'application, envisagez de vous y connecter en tant que ressource externe à l'aide de l'élément HTTPTargetConnection (comme décrit dans la documentation de référence sur la configuration du proxy d'API).

Remarque : La vidéo suivante montre l'éditeur de proxy classique dans l'interface utilisateur d'Apigee. Apigee intègre une nouvelle version de l'éditeur de proxys, dont la conception est différente de celle de la version classique présentée dans la vidéo.

Vidéo : visionnez une courte vidéo pour en savoir plus sur le chaînage de proxy d'API.

Fonctionnement de l'association de proxys en chaîne

L'association de proxys en chaîne utilise une connexion locale pour minimiser la surcharge du réseau lors d'un appel d'un proxy à partir d'un autre. Cette connexion locale est plus efficace, car elle contourne les fonctionnalités de réseau telles que les équilibreurs de charge, les routeurs et les sous-traitants de messages.

Vous trouverez ci-dessous la différence entre la connexion de proxys avec HTTPTargetConnection et LocalTargetConnection (chaînage de proxy) :

Vous connectez des proxys en spécifiant qu'un proxy est le point de terminaison cible local de l'autre. Pour la configuration du schéma ci-dessus ("Proxy-to-proxy call with proxy chaining", appel de proxy à proxy avec association de proxys en chaîne"), vous devez spécifier que ProxyB (/proxyB) est un point de terminaison cible local de ProxyA (/proxyA). Cela entraîne le transfert des requêtes arrivant à ProxyA vers ProxyB.

Vous pouvez créer une connexion locale entre les proxys de deux manières :

• En spécifiant le nom du proxy cible et un nom ProxyEndpoint
• En spécifiant un chemin d'accès au point de terminaison du proxy cible

Vous connectez des proxys cibles dans une configuration TargetEndpoint à l'aide d'un élément LocalTargetConnection, comme décrit ci-dessous.

Avertissement : Lorsque vous associez des proxys d'API en chaîne, veillez à éviter les appels récursifs en "boucle infinie" dans le même proxy d'API, qui peuvent entraîner une surcharge du système.

Connecter des proxys par nom de proxy

Vous pouvez spécifier le proxy cible par nom. Cela peut s'avérer particulièrement utile lorsque vous créez la connexion depuis le début et développez les proxys ensemble. Si vous ne connaissez pas le nom du proxy (ou si le nom est susceptible d'être modifié), envisagez de vous connecter au chemin du point de terminaison du proxy cible, comme décrit ci-dessous.

Lorsque vous vous connectez à un proxy cible par son nom, vous devez spécifier le nom du proxy et le nom de son ProxyEndpoint.

L'exemple suivant spécifie un proxy cible appelé data-manager, ainsi que le nom ProxyEndpoint exposé par data-manager. Pour plus d'informations, consultez la documentation de référence sur la configuration des proxys d'API.

Les éléments <APIProxy> et <ProxyEndpoint> acceptent la fonctionnalité de substitution de chaîne de variable appelée modélisation de message.

Important : Si vous implémentez un chaînage de proxys avec le nom du proxy, le deuxième proxy n'affichera pas de résultats dans Debug, même si vous appelez l'outil Debug pour lui. Utilisez plutôt le chaînage de proxys par chemin d'accès si vous devez utiliser Debug sur le deuxième proxy.

<TargetEndpoint name="datamanager">
    <PreFlow name="PreFlow">
        <!-- PreFlow policies -->
    </PreFlow>
    <PostFlow name="PostFlow">
        <!-- PostFlow policies -->
    </PostFlow>
    <LocalTargetConnection>
        <APIProxy>data-manager</APIProxy>
        <ProxyEndpoint>default</ProxyEndpoint>
    </LocalTargetConnection>
</TargetEndpoint>

Connecter des proxys par chemin

Vous pouvez spécifier le proxy cible en fonction du chemin d'accès de son point de terminaison. Cela peut s'avérer utile lorsque vous ne connaissez pas le nom du proxy ou lorsque celui-ci est susceptible d'être modifié.

Si votre proxy est simplement le consommateur du proxy cible, par exemple lorsque vous ne développez pas les deux, le chemin d'accès peut être le moyen le plus fiable de se connecter. Par exemple, si le proxy auquel vous vous connectez est développé et géré par une autre équipe, vous pouvez vous connecter à l'aide d'un chemin d'accès de point de terminaison fiable.

L'exemple suivant spécifie un proxy cible sur /v1/streetcarts/foodcarts/data-manager où l'hôte est supposé être identique au proxy actuel. Pour plus d'informations, consultez la documentation de référence sur la configuration des proxys d'API.

<TargetEndpoint name="datamanager">
    <PreFlow name="PreFlow">
        <!-- PreFlow policies -->
    </PreFlow>
    <PostFlow name="PostFlow">
        <!-- PostFlow policies -->
    </PostFlow>
    <LocalTargetConnection>
        <Path>/v1/streetcarts/foodcarts/data-manager</Path>
    </LocalTargetConnection>
</TargetEndpoint>

L'élément <Path> sous <LocalTargetConnection> peut être une chaîne, ou vous pouvez utiliser un modèle de message pour attribuer une valeur de manière dynamique.

Connecter des proxys à l'aide de l'interface utilisateur d'Apigee

Vous pouvez également connecter des proxys, par nom ou chemin d'accès, à l'aide de l'interface utilisateur d'Apigee. Dans l'exemple suivant, il y a deux proxys, ProxyA et ProxyB, et vous souhaitez que ProxyB soit un point de terminaison cible de ProxyA. Pour connecter les proxys par nom de proxy, procédez comme suit :

1. Connectez-vous à l'UI Apigee.
2. Sélectionnez Develop > Proxies (Développer > Proxys) dans le volet de gauche.
3. Dans la liste des proxys, sélectionnez ProxyA.
4. Cliquez sur l'onglet Develop (Développer).
5. Dans le volet Code, remplacez la section <TargetEndpoint> du fichier XML par les lignes suivantes :

   <TargetEndpoint>
     <LocalTargetConnection>
       <APIProxy>ProxyB</APIProxy>
       <ProxyEndpoint>default</ProxyEndpoint>
     </LocalTargetConnection>
   </TargetEndpoint>

6. Cliquez sur Save (Enregistrer).

Proxys en chaîne, produits API et sécurité

L'association de proxys en chaîne est préférable pour les cas où les deux proxys se trouvent dans le même produit API. Par défaut, les deux proxys sont disponibles pour les clients. Apigee ne permet actuellement pas de regrouper le deuxième proxy dans un produit d'API distinct auquel les clients ne devraient pas avoir accès.

Si votre deuxième proxy doit être sécurisé contre les requêtes client directs, envisagez d'ajouter une logique afin que votre deuxième proxy examine l'adresse IP du client. Dans le cas d'un appel effectué via l'association en chaîne, l'adresse IP sera locale. Votre code peut confirmer qu'il est local avant d'autoriser la poursuite du traitement. Pour savoir comment procéder, consultez la page Règle AccessControl.