Associer des proxys d'API en chaîne

<ph type="x-smartling-placeholder"></ph> Vous consultez la documentation Apigee Edge.
Accédez à la page Documentation sur Apigee X. En savoir plus

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.

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.

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.

Voici la différence entre la connexion de proxys à l'aide de 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. 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.

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.

<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 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>

Connecter les proxys à la gestion console

Vous pouvez créer des connexions en chaîne de proxy à l'aide de la console de gestion Edge.

  1. Ouvrez le proxy qui utilisera le proxy cible.
  2. Dans le Navigateur, cliquez sur le signe plus à côté de Points de terminaison cibles.
  3. Dans la boîte de dialogue Nouveau point de terminaison cible, saisissez le nom du point de terminaison cible.
  4. Sous la zone Nom du point de terminaison cible, sélectionnez l'une des options suivantes :
    • Chaînage de proxys pour effectuer une sélection à partir d'une liste de proxys déjà présents dans l'organisation et l'environnement.
      1. Dans la liste déroulante Nom du proxy, sélectionnez le proxy cible.
      2. Dans la zone Point de terminaison du proxy, saisissez le chemin d'accès au point de terminaison du proxy cible auquel vous souhaitez vous connecter.
    • Chaînage de chemins d'accès pour saisir le chemin d'accès de base du proxy cible, par exemple /mypath/myproxy/myendpoint.
  5. Cliquez sur Ajouter.

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.