Documentation de référence sur la configuration des proxys d'API

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

Consultez la documentation d'Apigee Edge.

En tant que développeur travaillant avec Apigee, vos activités de développement consistent principalement à configurer des serveurs d'API qui agissent comme des proxys pour les API ou les services de backend. Ce document fait référence à tous les éléments de configuration disponibles lors de la création de proxys d'API.

Si vous apprenez à créer des proxys d'API, nous vous recommandons de commencer par la rubrique Créer un proxy d'API simple.

Modifiez la configuration de votre proxy d'API de l'une des manières suivantes :

Passez par l'interface utilisateur ou l'API Apigee.
Téléchargez le groupe de configuration de proxy d'API, modifiez-le manuellement et importez la nouvelle configuration sur Apigee, comme décrit dans la section Télécharger et importer un groupe de configuration de proxy d'API.

Structure du répertoire de configuration du proxy API

La structure de répertoires de la configuration de proxy d'API est illustrée ci-dessous :

Affiche la structure de répertoire dans lequel apiproxy est la racine. Juste sous le répertoire apiproxy, vous trouverez les règles, les proxys, les ressources et les répertoires cibles, ainsi que le fichier weatherapi.xml.

Une configuration de proxy d'API comprend les éléments suivants :

Configuration de base	Principaux paramètres de configuration d'un proxy d'API.
ProxyEndpoint	Paramètres de la connexion HTTP entrante (de l'envoi d'applications à Apigee), les flux de requêtes et de réponses et les pièces jointes de règles.
TargetEndpoint	Paramètres pour la connexion HTTP sortante (depuis Apigee vers le service de backend), les flux de requêtes et de réponses, et les rattachements de règles.
Flux	Pipelines de requête et de réponse ProxyEndpoint et TargetEndpoint auxquels les règles peuvent être associées.
Règles	Fichiers de configuration au format XML conformes aux schémas des règles Apigee.
Ressources	Scripts, fichiers JAR et fichiers XSLT référencés par des règles pour exécuter une logique personnalisée.

Configuration de base

`/apiproxy/weatherapi.xml`

Configuration de base d'un proxy d'API, qui définit le nom du proxy API. Le nom doit être unique au sein d'une organisation.

Exemple de configuration :

<APIProxy name="weatherapi">
</APIProxy>

Éléments de configuration de base

Nom	Description	Par défaut	Requis ?
`APIProxy`
`name`	Nom du proxy d'API, qui doit être unique au sein d'une organisation. Les caractères que vous êtes autorisé à utiliser dans le nom sont limités aux éléments suivants : `A-Za-z0-9_-`	N/A	Oui
`revision`	Numéro de révision de la configuration de proxy de l'API. Vous n'avez pas besoin de définir explicitement le numéro de révision, car Apigee suit automatiquement la révision actuelle du proxy d'API.	N/A	Non
`ConfigurationVersion`	Version du schéma de configuration du proxy d'API auquel ce proxy d'API est conforme. La seule valeur actuellement acceptée est majorVersion 4 et minorVersion 0. Ce paramètre pourra être utilisé ultérieurement pour autoriser l'évolution du format de proxy d'API.	4.0	Non
`Description`	Description textuelle du proxy d'API. Si elle est fournie, la description s'affichera dans l'interface utilisateur d'Apigee.	N/A	Non
`DisplayName`	Un nom convivial qui peut être différent de l'attribut `name` de la configuration du proxy d'API.	N/A	Non
`Policies`	Liste des règles dans le répertoire `/policies` de ce proxy d'API. Généralement, vous ne verrez cet élément que lorsque le proxy d'API a été créé à l'aide de l'interface utilisateur Apigee. Il s'agit simplement d'un paramètre manifest conçu pour fournir une visibilité sur le contenu du proxy d'API.	N/A	Non
`ProxyEndpoints`	Liste des points de terminaison du proxy dans le répertoire `/proxies` de ce proxy d'API. Généralement, vous ne verrez cet élément que lorsque le proxy d'API a été créé à l'aide de l'interface utilisateur Apigee. Il s'agit simplement d'un paramètre manifest, conçu pour fournir une visibilité sur le contenu du proxy d'API.	N/A	Non
`Resources`	La liste des ressources (JavaScript, Python, Java, XSLT) dans le répertoire `/resources` de ce proxy d'API. Normalement, vous ne verrez cet élément que lorsque le proxy d'API a été créé à l'aide de l'interface utilisateur Apigee. Il s'agit simplement d'un paramètre manifest conçu pour fournir une visibilité sur le contenu du proxy d'API.	N/A	Non
`Spec`	Identifie la spécification OpenAPI associée au proxy d'API. La valeur est définie sur une URL ou sur un chemin d'accès dans le magasin de spécifications.	N/A	Non
`TargetServers`	Liste des serveurs cibles référencés dans n'importe quel point de terminaison cible du proxy d'API. Normalement, vous ne verrez cet élément que lorsque le proxy d'API a été créé à l'aide d'Apigee. Il s'agit simplement d'un paramètre manifest conçu pour fournir une visibilité sur le contenu du proxy d'API.	N/A	Non
`TargetEndpoints`	Liste des points de terminaison cibles dans le répertoire `/targets` de ce proxy d'API. Normalement, vous ne verrez cet élément que lorsque le proxy d'API a été créé à l'aide de l'interface utilisateur Apigee. Il s'agit simplement d'un paramètre manifest, conçu pour fournir une visibilité sur le contenu du proxy d'API.	N/A	Non

ProxyEndpoint

L'image suivante montre le flux de requêtes/réponses :

Affiche un client appelant un service HTTP. La requête passe par le point de terminaison proxy, puis le point de terminaison cible avant d'être traité par le service HTTP. La réponse passe par le point de terminaison cible, puis le point de terminaison du proxy avant d'être renvoyé au client.

`/apiproxy/proxies/default.xml`

La configuration ProxyEndpoint définit l'interface entrante (destinée au client) d'un proxy d'API. Lorsque vous configurez un point de terminaison du proxy, vous paramétrez une configuration réseau qui définit la façon dont les applications clientes (apps) doivent appeler l'API avec proxy.

L'exemple de configuration ProxyEndpoint suivant serait stocké sous /apiproxy/proxies :

<ProxyEndpoint name="default">
  <PreFlow/>
  <Flows/>
  <PostFlow/>
  <HTTPProxyConnection>
    <BasePath>/weather</BasePath>
    <Properties/>
  </HTTPProxyConnection>
  <FaultRules/>
  <DefaultFaultRule/>
  <RouteRule name="default">
    <TargetEndpoint>default</TargetEndpoint>
  </RouteRule>
</ProxyEndpoint>

Les éléments de configuration requis dans un point de terminaison du proxy sont les suivants :

Éléments de configuration ProxyEndpoint

Nom Description Par défaut Requis ?

ProxyEndpoint

name Nom du point de terminaison du proxy. Doit être unique dans la configuration du proxy d'API, lorsque, dans de rares cas, plusieurs points de terminaison du proxy sont définis. Les caractères que vous êtes autorisé à utiliser dans le nom sont limités aux éléments suivants : A-Za-z0-9._\-$ % N/A Oui

PreFlow Définit les règles dans le flux PreFlow d'une requête ou d'une réponse. N/A Oui

Flows

Définit les règles dans les flux conditionnels d'une requête ou d'une réponse.

N/A

Oui

PostFlow

Définit les règles dans le flux PostFlow d'une requête ou d'une réponse.

N/A

Oui

HTTPProxyConnection Définit l'adresse réseau et le chemin d'URI associés au proxy d'API.

BasePath

Chaîne obligatoire qui identifie de manière unique le chemin d'URI utilisé par Apigee pour acheminer les messages entrants vers le proxy d'API approprié.

BasePath est un fragment d'URI (par exemple, /weather) ajouté à l'URL de base d'un proxy d'API (par exemple, http://apifactory-test.apigee.net). BasePath doit être unique au sein d'un environnement. L'unicité est validée lorsqu'un proxy d'API est généré ou importé.

Utiliser un caractère générique dans les chemins de base

Vous pouvez utiliser un ou plusieurs caractères génériques "*" dans les chemins d'accès de base du proxy d'API. Par exemple, un chemin de base de /team/*/members permet aux clients d'appeler https://[host]/team/blue/members et https://[host]/team/green/members sans que vous ayez besoin de créer de proxys d'API pour gérer les nouvelles équipes. Notez que /**/ n'est pas accepté.

Important : Apigee n'accepte PAS le caractère générique "*" en tant que premier élément d'un chemin de base. Par exemple, ceci n'est PAS accepté : /*/search. Commencer le chemin de base par un "*" peut entraîner des erreurs inattendues, en raison de la manière dont Apigee identifie les chemins valides.

Oui

Properties

Un ensemble de paramètres de configuration HTTP facultatifs peut être défini en tant que propriétés d'un objet <ProxyEndpoint>.

Utilisez la propriété request.queryparams.ignore.content.type.charset pour indiquer au proxy d'ignorer le paramètre charset de l'en-tête Content-Type lors du traitement de l'URL de la requête. Par exemple :

<Property name= \
"request.queryparams.ignore.content.type.charset">true</>

Le tableau suivant présente un exemple de résultat en fonction du paramètre de la propriété charset et de la présence du paramètre charset de l'en-tête Content-Type.

Paramètre de la propriété	Valeur d’en-tête	Exemple de résultat :
`charset=false`	Paramètre `charset` non défini	john.doe+test@gmail.com
`charset=false`	`charset=utf-8`	john.doe test@gmail.com
`charset=true` et aucun paramètre `charset` dans l'en-tête	Paramètre `charset` non défini	john.doe+test@gmail.com
`charset=true`	Paramètre `charset=utf-8` défini	john.doe+test@gmail.com

N/A

Non

FaultRules

Définit la manière dont le point de terminaison du proxy réagit à une erreur. Une règle d'erreur spécifie les deux éléments suivants :

Une condition qui spécifie l'erreur à gérer en fonction de la catégorie, de la sous-catégorie ou du nom prédéfinis de l'erreur.
Une ou plusieurs règles qui définissent le comportement de la règle d'erreur pour la condition correspondante.

Consultez la page Gérer les erreurs.

N/A

Non

DefaultFaultRule

Gère toutes les erreurs (système, transport, messagerie ou règle) qui ne sont pas explicitement gérées par une autre règle d'erreur.

Consultez la page Gérer les erreurs.

N/A

Non

RouteRule Définit la destination des messages de requête entrants après avoir été traités par le pipeline de requêtes ProxyEndpoint. En général, la règle RouteRule pointe vers un point de terminaison cible, un IntegrationEndpoint ou une URL nommé.

Name Attribut requis, qui fournit un nom pour la règle "RouteRule". Les caractères que vous êtes autorisé à utiliser dans le nom sont limités aux éléments suivants : A-Za-z0-9._\-$ % Par exemple, Cat2 %_ est un nom légal. N/A Oui

Condition Instruction conditionnelle facultative utilisée pour le routage dynamique lors de l'exécution. Les règles de routage conditionnelles sont utiles, par exemple, pour permettre un routage basé sur le contenu afin d'assurer la gestion des versions du backend. N/A Non

TargetEndpoint

Chaîne facultative qui identifie une configuration TargetEndpoint nommée. Un point de terminaison cible nommé est un objet point de terminaison cible défini dans le même proxy d'API sous le répertoire /targets).

En nommant un point de terminaison cible, vous spécifiez où les messages de requête doivent être transférés après le traitement par le pipeline de requêtes ProxyEndpoint. Notez qu'il s'agit d'un paramètre facultatif.

Un point de terminaison du proxy peut appeler directement une URL. Par exemple, une ressource JavaScript ou Java, fonctionnant en tant que client HTTP, peut effectuer la responsabilité de base d'un point de terminaison cible, qui consiste à transférer les requêtes vers un service de backend.

N/A

Non

URL Chaîne facultative qui définit une adresse réseau sortante appelée par le point de terminaison du proxy, en ignorant les configurations TargetEndpoint susceptibles d'être stockées sous /targets N/A Non

Comment configurer des règles de routage

Un point de terminaison cible nommé fait référence à un fichier de configuration sous /apiproxy/targets, dans lequel la règle RouteRule transfère une requête après le traitement par point de terminaison du proxy.

Par exemple, la règle RouteRule suivante fait référence à la configuration /apiproxy/targets/myTarget.xml :

<RouteRule name="default">
  <TargetEndpoint>myTarget</TargetEndpoint>
</RouteRule>

Appel direct d'URL

Un point de terminaison du proxy peut également appeler directement un service de backend. L'appel direct d'URL contourne toute configuration de point de terminaison cible nommée sous /apiproxy/targets. Pour cette raison, le point de terminaison cible est une configuration facultative de proxy d'API, bien qu'en pratique, l'appel direct à partir du point de terminaison du proxy ne soit pas recommandé.

Par exemple, la règle RouteRule suivante envoie un appel HTTP à http://api.mycompany.com/v2.

<RouteRule name="default">
  <URL>http://api.mycompany.com/v2</URL> 
</RouteRule>

Routes conditionnelles

Les règles RouteRules peuvent être associées pour accepter le routage dynamique lors de l'exécution. Les requêtes entrantes peuvent être acheminées vers des configurations TargetEndpoint nommées, directement vers des URL ou une combinaison des deux, en fonction des en-têtes HTTP, du contenu du message, des paramètres de requête ou des informations contextuelles telles que l'heure, paramètres régionaux, etc.

Les règles de routage conditionnelles fonctionnent comme les autres instructions conditionnelles sur Apigee. Consultez la documentation de référence sur les conditions et les variables de flux.

Par exemple, la combinaison RouteRule suivante permet d'évaluer d'abord la requête entrante pour vérifier la valeur d'un en-tête HTTP. Si l'en-tête HTTP routeTo comporte la valeur TargetEndpoint1, la requête est transmise au point de terminaison cible nommé TargetEndpoint1. Si ce n'est pas le cas, la requête entrante est transmise à http://api.mycompany.com/v2.

<RouteRule name="MyRoute">
  <Condition>request.header.routeTo = "TargetEndpoint1"</Condition>
  <TargetEndpoint>TargetEndpoint1</TargetEndpoint>
</RouteRule>
<RouteRule name="default">
  <URL>http://api.mycompany.com/v2</URL>
</RouteRule>

Routes Null

Une valeur RouteRule nulle peut être définie pour accepter des scénarios dans lesquels le message de requête n'a pas besoin d'être transmis au point de terminaison cible. Cela s'avère utile lorsqu'un point de terminaison du proxy effectue tous les traitements nécessaires, par exemple en utilisant JavaScript pour appeler un service externe ou récupérer des données à partir d'une recherche dans le magasin de clés/valeurs des services d'API.

Par exemple, ce qui suit définit une route nulle :

<RouteRule name="GoNowhere"/>

Les routes conditionnelles nulles peuvent être utiles. Dans l'exemple suivant, une route nulle est configurée pour s'exécuter lorsqu'un en-tête HTTP request.header.X-DoNothing possède une valeur autre que null.

<RouteRule name="DoNothingOnDemand">
  <Condition>request.header.X-DoNothing != null</Condition>
</RouteRule>

Rappelez-vous : les routesRules peuvent être enchaînées. Par conséquent, une route conditionnelle nulle est généralement un composant d'un ensemble de règles de route conçues pour prendre en charge le routage conditionnel.

Une route conditionnelle nulle peut être utile pour la compatibilité de la mise en cache. En utilisant la valeur de la variable définie par la stratégie de mise en cache, vous pouvez configurer un proxy d'API pour qu'il exécute la route nulle lorsqu'une entrée est diffusée à partir du cache.

<RouteRule name="DoNothingUnlessTheCacheIsStale">
  <Condition>lookupcache.LookupCache-1.cachehit is true</Condition>
</RouteRule>

Point de terminaison cible

Un point de terminaison cible est l'équivalent sortant d'un point de terminaison du proxy. Un point de terminaison cible fonctionne en tant que client d'une API ou d'un service de backend : il envoie des requêtes et reçoit des réponses.

Un proxy d'API n'a pas besoin de point de terminaison cible. Les points de terminaison du proxy peuvent être configurés pour appeler directement les URL. Un proxy d'API sans point de terminaison cible contient généralement un point de terminaison de proxy qui appelle directement un service de backend, ou est configuré pour appeler un service à l'aide de Java ou de JavaScript.

Configuration de TargetEndpoint

`/targets/default.xml`

Le point de terminaison cible définit la connexion sortante d'Apigee vers un autre service ou une autre ressource.

Voici un exemple de configuration TargetEndpoint :

<TargetEndpoint name="default">
  <PreFlow/>
  <Flows/>
  <PostFlow/>
  <HTTPTargetConnection>
    <URL>http://mocktarget.apigee.net</URL>
    <SSLInfo/>
    <Authentication/>
  </HTTPTargetConnection>
  <FaultRules/>
  <DefaultFaultRule/>
  <ScriptTarget/>
  <LocalTargetConnection/>
</TargetEndpoint>

Éléments de configuration TargetEndpoint

Un point de terminaison cible peut appeler une cible de l'une des manières suivantes :

HTTPTargetConnection pour les appels HTTP ou HTTPS
LocalTargetConnection pour le chaînage local de proxy à proxy

Configurez un seul de ces éléments dans un point de terminaison cible.

Nom	Description	Par défaut	Requis ?
`TargetEndpoint`
`name`	Nom du point de terminaison cible, qui doit être unique dans la configuration du proxy d'API. Le nom du point de terminaison cible est utilisé dans la règle de routage ProxyEndpoint pour diriger les requêtes en vue d'un traitement sortant. Les caractères que vous êtes autorisé à utiliser dans le nom sont limités aux éléments suivants : `A-Za-z0-9._\-$ %`	N/A	Oui
`PreFlow`	Définit les règles dans le flux PreFlow d'une requête ou d'une réponse.	N/A	Oui
`Flows`	Définit les règles dans les flux conditionnels d'une requête ou d'une réponse.	N/A	Oui
`PostFlow`	Définit les règles dans le flux PostFlow d'une requête ou d'une réponse.	N/A	Yes
`HTTPTargetConnection`	Avec ses éléments enfants, spécifie une ressource de backend atteinte via HTTP. Si vous utilisez HTTPTargetConnection, ne configurez pas d'autres types de connexions cibles (ScriptTarget ou LocalTargetConnection). Remarque : Les éléments `<LocalTargetConnection>` acceptent la fonctionnalité de substitution de chaîne de variable appelée modélisation de message. Vous pouvez utiliser l'élément enfant `<Authentication>` pour effectuer des appels authentifiés aux services Google ou aux services personnalisés exécutés sur certains produits Google Cloud, tels que Cloud Functions et Cloud Run. L'utilisation de l'élément `<Authentication>` nécessite de suivre les étapes de configuration et de déploiement décrites dans la section Utiliser l'authentification Google. Avec une configuration appropriée, la règle crée un jeton d'authentification et l'ajoute à la demande de service. Consultez également la section Utilisation de l'élément `<Authentication>`.
`URL`	Définit l'adresse réseau du service de backend vers lequel le point de terminaison cible transmet les messages de requête.	N/A	Non
`LoadBalancer`	Définit une ou plusieurs configurations TargetServer nommées. Les configurations TargetServer nommées peuvent servir à l'équilibrage de charge définissant deux ou plusieurs connexions de configuration de point de terminaison. Vous pouvez également utiliser les serveurs cibles pour dissocier les configurations de proxy d'API des URL concrètes de points de terminaison du service de backend.	N/A	Non
`Properties`	Un ensemble de paramètres de configuration HTTP facultatifs peut être défini en tant que propriétés d'un objet `<TargetEndpoint>`.	N/A	Non
`SSLInfo`	Vous pouvez éventuellement définir des paramètres TLS/SSL sur un point de terminaison cible pour contrôler la connexion TLS/SSL entre le proxy d'API et le service cible. Consultez la page Configuration TLS/SSL TargetEndpoint. Remarque : L'élément `<SSLInfo>` accepte la fonctionnalité de substitution de chaîne de variable appelée modélisation de message.	N/A	Non
`LocalTargetConnection`	Avec ses éléments enfants, spécifie une ressource à atteindre localement en ignorant les caractéristiques réseau, telles que l'équilibrage de charge et les processeurs de messages. Pour spécifier la ressource cible, incluez soit l'élément enfant APIProxy (avec l'élément ProxyEndpoint), soit l'élément enfant Path. Pour plus d'informations, consultez la section Chaîner des proxys d'API. Si vous utilisez LocalTargetConnection, ne configurez pas d'autres types de connexions cibles (HTTPTargetConnection ou ScriptTarget).
`APIProxy`	Spécifie le nom d'un proxy API à utiliser comme cible pour les requêtes. Le proxy cible doit appartenir à la même organisation et à l'environnement que le proxy qui envoie les requêtes. Ceci constitue une alternative à l'utilisation de l'élément Path.	N/A	Non
`ProxyEndpoint`	Utilisé avec APIProxy pour spécifier le nom du point de terminaison du proxy cible.	N/A	Non
`Path`	Spécifie le chemin d'accès au point de terminaison d'un proxy d'API à utiliser comme cible pour les requêtes. Le proxy cible doit appartenir à la même organisation et à l'environnement que le proxy qui envoie les requêtes. Il s'agit d'une alternative à l'utilisation d'APIProxy.	N/A	Non
`FaultRules`	Définit la manière dont le point de terminaison cible réagit à une erreur. Une règle d'erreur spécifie les deux éléments suivants : Une condition qui spécifie l'erreur à gérer en fonction de la catégorie, de la sous-catégorie ou du nom prédéfinis de l'erreur. Une ou plusieurs règles qui définissent le comportement de la règle d'erreur pour la condition correspondante. Consultez la page Gérer les erreurs.	N/A	Non
`DefaultFaultRule`	Gère toutes les erreurs (système, transport, messagerie ou règle) qui ne sont pas explicitement gérées par une autre règle FaultRule. Consultez la page Gérer les erreurs.	N/A	Non

Utilisation de l'élément `<Authentication>`

L'utilisation de l'élément <Authentication> dans <TargetEndpoint> est identique à l'utilisation de l'élément <Authentication> dans la règle ServiceCallout. Dans <TargetEndpoint> et ServiceCallout, <Authentication> est un sous-élément de <HttpTargetConnection>. Pour en savoir plus, consultez la section Élément Authentication dans la documentation de référence de la règle ServiceCallout.

Référence d'erreur de l'élément `<Authentication>`

Si vous utilisez l'élément <Authentication>, vous trouverez des messages d'erreur possibles et des conseils de dépannage pour les erreurs de déploiement et d'exécution dans la section Erreurs de la documentation sur la règle ServiceCallout.

Exemples de l'élément `<Authentication>`

L'exemple suivant montre comment appeler un service déployé sur Cloud Run en tant que cible à l'aide de l'élément Authentication afin de générer un jeton OpenID Connect nécessaire à l'authentification de l'appel :

<TargetEndpoint name="TargetEndpoint-1">
  <HTTPTargetConnection>
      <Properties/>
      <URL>https://cloudrun-hostname.a.run.app/test</URL>
      <Authentication>
          <GoogleIDToken>
             <Audience>https://cloudrun-hostname.a.run.app/test</Audience>
          </GoogleIDToken>
     </Authentication>
  </HTTPTargetConnection>
</TargetEndpoint>

L'exemple suivant montre comment appeler un service cible (TargetService) qui pointe vers Cloud Run à l'aide de l'élément Authentication pour générer un jeton OpenID Connect nécessaire à l'authentification de l'appel. L'élément HeaderName ajoute le jeton de support généré à un en-tête nommé X-Serverless-Authorization, qui est envoyé au système cible. L'en-tête Authorization, s'il est présent, est conservé tel quel et est également envoyé dans la requête.

<TargetEndpoint name="TargetEndpoint-1">
   <HTTPTargetConnection>
     <Authentication>
        <HeaderName>X-Serverless-Authorization</HeaderName>
        <GoogleIDToken>
            <Audience ref="flow.variable.audience">https://cloudrun-hostname.a.run.app</Audience>
        </GoogleIDToken>
     </Authentication>
      <LoadBalancer>
         <Server name="cloud-run-target" />
      </LoadBalancer>
   </HTTPTargetConnection>
</TargetEndpoint>

L'exemple suivant montre comment appeler un service cible (TargetService) qui pointe vers le service Secret Manager de Google. Dans cet exemple, l'élément GoogleAccessToken est configuré pour générer un jeton d'authentification Google afin d'authentifier la requête cible :

<HTTPTargetConnection>
   <Authentication>
      <GoogleAccessToken>
        <Scopes>
          <Scope>https://www.googleapis.com/auth/cloud-platform</Scope>
        </Scopes>
      </GoogleAccessToken>
    </Authentication>
    <URL>
      https://secretmanager.googleapis.com/v1/projects/project-id/secrets/secret-id
    </URL>
</HTTPTargetConnection>

L'exemple suivant montre comment définir automatiquement l'audience du jeton GoogleIDToken. Lorsque la valeur de useTargetUrl est true et que la variable référencée ne correspond pas à une variable valide, l'URL de la cible (à l'exclusion des paramètres de requête) est utilisée comme audience. Supposons que le chemin de la requête soit /foobar et que l'URL du serveur cible soit https://xyz.com, l'audience du GoogleIDToken est automatiquement définie sur https://xyz.com/foobar.

Utilisateurs d'Apigee hybrid : si vous utilisez Apigee hybrid, notez que l'attribut useTargetUrl est disponible dans les versions 1.8 et ultérieures d'Apigee hybrid.

<TargetEndpoint name="TargetEndpoint-1">
  <HTTPTargetConnection>
    <Authentication>
      <GoogleIDToken>
        <Audience ref='myvariable' useTargetUrl="true"/>
      </GoogleIDToken>
    </Authentication>
    <LoadBalancer>
      <Server name="TS" />
    </LoadBalancer>
  </HTTPTargetConnection>
</TargetEndpoint>

Configuration de TLS/SLL TargetEndpoint

Les points de terminaison cibles doivent souvent gérer les connexions HTTPS avec une infrastructure de backend hétérogène. C'est la raison pour laquelle un certain nombre de paramètres de configuration TLS/SSL sont acceptés.

Éléments de configuration TargetEndpoint TLS/SSL

Nom	Description	Par défaut	Requis ?
`SSLInfo`
`Enabled`	Le bloc `<SSLInfo>` peut être utilisé pour les protocoles TLS/SSL unidirectionnels et bidirectionnels. Si la valeur est `true`, `<Enabled>` indique que le bloc `<SSLInfo>` doit être utilisé. Lorsque ce paramètre est défini sur `false`, le bloc `<SSLInfo>` est ignoré. La valeur par défaut de `<Enabled>` est `true` si `<URL>` spécifie le protocole HTTPS et `false` si `<URL>` spécifie HTTP.	La valeur est définie sur "true" si `<URL>` spécifie le protocole HTTPS.	Non
`Enforce`	Applique le protocole SSL strict entre Apigee et le backend cible. Si la valeur est définie sur `true`, les connexions échouent pour les cibles avec des certificats non valides, des certificats expirés, des certificats autosignés, des certificats avec un nom d'hôte incompatible et des certificats avec une racine non approuvée. Un code d'échec `4xx` ou `5xx` est renvoyé. Si cette valeur n'est pas définie ou est définie sur `false`, le résultat des connexions aux backends cibles avec des certificats problématiques dépend du paramètre `<IgnoreValidationErrors>` (voir ci-dessous). Une réponse positive (`2xx`) peut se produire dans certaines conditions, si `<IgnoreValidationErrors>` est défini sur `true`.	`false`	Non
`TrustStore`	Un keystore contenant des certificats de serveur approuvés	N/A	Non
`ClientAuthEnabled`	Active le protocole TLS bidirectionnel (également appelé TLS mutuel ou mTLS) entre Apigee et le client API, ou entre Apigee et le backend cible. L'activation du TLS bidirectionnel nécessite généralement de configurer un truststore sur Apigee et un truststore.	`false`	Non
`KeyStore`	Magasin de clés contenant des clés privées utilisées pour l'authentification du client sortant	N/A	Oui (si ClientAuthEnabled est défini sur "true")
`KeyAlias`	Alias de la clé privée utilisée pour l'authentification du client sortant	N/A	Oui (si ClientAuthEnabled est défini sur "true")
`IgnoreValidationErrors`	Indique si les erreurs de validation sont ignorées. Si le système backend utilise SNI et renvoie un certificat dont le nom distinctif (DN) de l'objet ne correspond pas au nom d'hôte, il est impossible d'ignorer l'erreur et la connexion échoue. Remarque : Si la valeur de `<Enforce>` est définie sur `true`, la valeur de `<IgnoreValidationErrors>` est ignorée.	`false`	Non
`Ciphers`	Algorithmes de chiffrement compatibles avec TLS/SSL sortant Si aucun algorithme n'est spécifié, tous les algorithmes de chiffrement disponibles pour la JVM sont autorisés. Pour limiter les algorithmes de chiffrement, ajoutez les éléments suivants, répertoriant les algorithmes de chiffrement compatibles : <Ciphers> <Cipher>TLS_RSA_WITH_3DES_EDE_CBC_SHA</Cipher> <Cipher>TLS_RSA_WITH_DES_CBC_SHA</Cipher> </Ciphers>	N/A	Non
`Protocols`	Protocoles compatibles pour le protocole TLS/SSL sortant Si aucun protocole n'est spécifié, tous les protocoles disponibles pour la JVM seront autorisés. Pour limiter les protocoles, spécifiez-les explicitement. Par exemple, pour n'autoriser que TLS v1.2 ou TLS v1.3 : <Protocols> <Protocol>TLSv1.2</Protocol> <Protocol>TLSv1.3</Protocol> </Protocols>	N/A	Non
`CommonName`	Nom commun TLS du certificat	N/A	Non

Exemple de point de terminaison cible avec authentification client sortante activée

<TargetEndpoint name="default">
  <HttpTargetConnection>
        <URL>https://myservice.com</URL>
    <SSLInfo>
      <Enabled>true</Enabled>
      <Enforce>true</Enforce>
      <ClientAuthEnabled>true</ClientAuthEnabled>
      <KeyStore>myKeystore</KeyStore>
      <KeyAlias>myKey</KeyAlias>
      <TrustStore>myTruststore</TrustStore>
    </SSLInfo>
  </HttpTargetConnection>
</TargetEndpoint>

Pour obtenir des instructions détaillées, consultez la section Configurer TLS.

Utiliser des variables de flux pour définir des valeurs TLS/SSL de manière dynamique

Vous pouvez également définir de manière dynamique les détails TLS/SSL pour répondre aux exigences d'exécution flexible. Par exemple, si votre proxy se connecte à deux cibles potentiellement différentes (une cible de test et une cible de production), vous pouvez configurer votre proxy d'API de manière automatisée pour déterminer quel environnement est appelé et définir de manière dynamique des références au keystore et au truststore appropriés. L'article de la communauté Apigee Dynamic SSLInfo for TargetEndpoint using variable reference explique en détail ce scénario et fournit des exemples de proxy d'API déployables.

Dans l'exemple suivant, la valeur du tag <SSLInfo> est définie dans une configuration TargetEndpoint, et les valeurs peuvent être fournies lors de l'exécution, par exemple dans un appel Java, une règle JavaScript ou une règle AssignMessage. Utilisez les variables de message qui contiennent les valeurs que vous souhaitez définir.

Les variables ne sont autorisées que dans les éléments suivants.

<SSLInfo>
    <Enabled>{myvars.ssl.enabled}</Enabled>
    <ClientAuthEnabled>{myvars.ssl.client.auth.enabled}</ClientAuthEnabled>
    <KeyStore>{myvars.ssl.keystore}</KeyStore>
    <KeyAlias>{myvars.ssl.keyAlias}</KeyAlias>
    <TrustStore>{myvars.ssl.trustStore}</TrustStore>
</SSLInfo>

Utiliser des références pour définir les valeurs TLS/SSL de manière dynamique

Lorsque vous configurez un point de terminaison cible qui utilise HTTPS, vous devez prendre en compte le cas où le certificat TLS/SSL expire ou lorsqu'une modification apportée à la configuration système nécessite une mise à jour du certificat.

Pour en savoir plus, consultez la section Gérer des certificats expirés.

Cependant, vous pouvez éventuellement configurer le point de terminaison cible pour utiliser une référence au keystore ou au truststore à la place. L'avantage d'utiliser une référence est que vous pouvez mettre à jour la référence pour qu'elle pointe vers un autre keystore ou truststore afin de mettre à jour le certificat TLS/SSL sans avoir à redémarrer les processeurs de message.

Par exemple, vous trouverez ci-dessous un point de terminaison cible qui utilise une référence au magasin de clés :

<SSLInfo>
  <Enabled>true</Enabled>
  <ClientAuthEnabled>false</ClientAuthEnabled>
  <KeyStore>ref://keystoreref</KeyStore>
  <KeyAlias>myKeyAlias</KeyAlias>
</SSLInfo>

Utilisez l'appel d'API POST suivant pour créer la référence nommée keystoreref :

curl "https://apigee.googleapis.com/v1/organizations/{org}/environments/{org}/references" \
  -X POST \
  -H "Authorization: Bearer $TOKEN" \
  -d '<ResourceReference name="keystoreref">
    <Refers>myTestKeystore</Refers>
    <ResourceType>KeyStore</ResourceType>
</ResourceReference>'

Où $TOKEN est défini sur votre jeton d'accès OAuth 2.0, comme décrit dans la section Obtenir un jeton d'accès OAuth 2.0. Pour en savoir plus sur les options curl utilisées dans cet exemple, consultez la section Utiliser curl. Pour obtenir une description des variables d'environnement utilisées, consultez la section Définir des variables d'environnement pour les requêtes API Apigee.

La référence spécifie le nom du magasin de clés et son type.

Utilisez l'appel d'API GET suivant pour afficher la référence :

curl "https://apigee.googleapis.com/v1/organizations/{org}/environments/{org}/references/keystoreref" \
  -H "Authorization: Bearer $TOKEN"

curl "https://apigee.googleapis.com/v1/organizations/{org}/environments/{org}/references/keystoreref" \
  -H "Authorization: Bearer $TOKEN"

Pour modifier ultérieurement la référence afin qu'elle pointe vers un magasin de clés différent, assurez-vous que l'alias porte le même nom, utilisez l'appel PUT suivant :

curl "https://apigee.googleapis.com/v1/organizations/{org}/environments/{org}/references/keystoreref" \
  -X PUT \
  -H "Authorization: Bearer $TOKEN" \
  -d '<ResourceReference name="keystoreref">
    <Refers>myNewKeystore</Refers>
    <ResourceType>KeyStore</ResourceType>
  </ResourceReference>'

TargetEndpoint avec un équilibrage de charge cible

Les points de terminaison cibles acceptent l'équilibrage de charge sur plusieurs serveurs cibles nommés à l'aide de trois algorithmes d'équilibrage de charge de type.

Pour obtenir des instructions détaillées, reportez-vous à la section Équilibrage de charge sur les serveurs backend.

IntegrationEndpoint

Un IntegrationEndpoint est un point de terminaison cible qui exécute spécifiquement des intégrations Apigee. Si vous avez configuré un IntegrationEndpoint, Apigee envoie l'objet request à la plate-forme d'intégration d'Apigee pour l'exécuter. En plus de configurer le point de terminaison IntegrationEndpoint, vous devez également ajouter la règle SetIntegrationRequest dans le flux de votre proxy pour exécuter votre intégration.

Vous pouvez configurer votre intégration pour qu'elle s'exécute de manière synchrone ou asynchrone en définissant l'élément <AsyncExecution> dans la configuration IntegrationEndpoint. Pour en savoir plus, consultez la section Exécution synchrone et asynchrone. Une fois l'intégration exécutée, Apigee enregistre la réponse dans le message de réponse.

Remarque : Vous avez besoin d'un jeton d'authentification pour exécuter le point de terminaison IntegrationEndpoint. Cependant, il n'y a pas d'élément <Authentication> explicite dans la définition IntegrationEndpoint. Apigee ajoute un jeton d'authentification à la requête en arrière-plan. Pour authentifier IntegrationEndpoint, vous devez déployer votre proxy d'API avec un compte de service disposant des rôles IAM requis pour exécuter une intégration. Pour en savoir plus sur les rôles requis, consultez la section Rôles IAM pour les intégrations. Pour en savoir plus sur le déploiement d'un proxy d'API, consultez la section Déployer sur Apigee.

Configurer IntegrationEndpoint

Pour configurer un point de terminaison d'intégration comme point de terminaison cible, ajoutez l'élément IntegrationEndpoint à votre configuration ProxyEndpoint. Voici un exemple de configuration ProxyEndpoint :

<ProxyEndpoint name="default">
    <Description/>
    <FaultRules/>
    <PreFlow name="PreFlow">
        <Request>
            <Step>
                <Name>my-set-integration-request-policy</Name>
            </Step>
        </Request>
    </PreFlow>
    <Flows/>
    <PostFlow name="PostFlow"/>
    <HTTPProxyConnection>
        <BasePath>/integration-endpoint-test</BasePath>
        <Properties/>
    </HTTPProxyConnection>
    <RouteRule name="default">
        <IntegrationEndpoint>my-int-endpoint</IntegrationEndpoint>
    </RouteRule>
</ProxyEndpoint>

Dans l'exemple de configuration ProxyEndpoint, Apigee effectue les tâches suivantes :

Dans le PreFlow, il exécute la règle nommée my-set-integration-request-policy, qui définit l'objet de la requête d'intégration et les variables du flux d'intégration.
Il utilise my-int-endpoint comme point de terminaison cible, comme spécifié dans la règle RouteRule.
Il lit l'objet de la requête d'intégration créé par my-set-integration-request-policy.
Il envoie la requête à la plate-forme d'intégration d'Apigee à l'aide de l'objet de la requête et des variables de flux définies par la règle SetIntegrationRequest.
Il enregistre la réponse de l'intégration dans le message de réponse.

Le fichier XML contenant la déclaration <IntegrationEndpoint> est disponible dans le répertoire APIGEE_BUNDLE_DIRECTORY/apiproxy/integration-endpoints/. Si vous créez votre proxy d'API à l'aide de l'option Develop > API Proxies > CREATE NEW > Integration target, Apigee stocke la déclaration dans le fichier /apiproxy/integration-endpoints/default.xml. Si vous créez le fichier XML du point de terminaison d'intégration à partir de l'UI, vous pouvez personnaliser son nom.

L'exemple suivant montre la déclaration de l'élément <IntegrationEndpoint> dans le fichier XML :

<IntegrationEndpoint name="my-int-endpoint">
    <AsyncExecution>false</AsyncExecution>
</IntegrationEndpoint>

Éléments de configuration de IntegrationEndpoint

Nom	Description	Par défaut	Requis ?
`IntegrationEndpoint`
`name`	Nom du point de terminaison IntegrationEndpoint. Les caractères que vous pouvez utiliser dans le nom se limitent à : `A-Za-z0-9._\-$ %`	N/A	Yes
`AsyncExecution`	Valeur booléenne indiquant si l'intégration doit s'exécuter en mode synchrone ou asynchrone. Pour en savoir plus, consultez la section Exécution synchrone et asynchrone.	faux	Non

Exécution synchrone et asynchrone

Vous pouvez configurer l'intégration pour qu'elle s'exécute en mode synchrone ou asynchrone. Pour comprendre la différence entre ces deux modes d'exécution, consultez la section <AsyncExecution>.

Utilisez l'élément <AsyncExecution> de </IntegrationEndpoint> pour spécifier une exécution synchrone ou asynchrone. Si vous définissez <AsyncExecution> sur true, l'intégration s'exécute de manière asynchrone. Si vous définissez cet élément sur false, l'intégration s'exécute de manière synchrone.

L'exemple suivant définit l'élément AsyncExecution sur true :

<IntegrationEndpoint name="my-int-endpoint">
    <AsyncExecution>true</AsyncExecution>
</IntegrationEndpoint>

Stratégies

Le répertoire /policies d'un proxy d'API contient toutes les stratégies pouvant être associées aux flux dans le proxy d'API.

Éléments de configuration de la stratégie

Nom	Description	Par défaut	Requis ?
`Policy`
`name`	Nom interne de la règle. Les caractères que vous pouvez utiliser dans le nom se limitent à : `A-Za-z0-9._\-$ %`. L'interface utilisateur Apigee applique cependant des restrictions supplémentaires, telles que la suppression automatique des caractères qui ne sont pas alphanumériques. Vous pouvez également utiliser l'élément `<DisplayName>` pour ajouter un libellé à la règle dans l'éditeur de proxy de l'interface utilisateur d'Apigee, en utilisant un nom différent, en langage naturel.	N/A	Oui
`enabled`	Définissez sur `true` pour appliquer la règle. Définissez sur `false` pour désactiver la règle. La stratégie ne sera pas appliquée, même si elle reste associée à un flux.	`true`	Non
`continueOnError`	Définissez sur `false` pour afficher une erreur en cas d'échec d'une règle. Il s'agit du comportement attendu pour la plupart des règles. Définissez sur `true` pour que l'exécution du flux se poursuive même après l'échec d'une règle.	`false`	Non
`async`	Remarque : Cet attribut n'applique pas la règle de manière asynchrone. Dans la plupart des cas, conservez la valeur par défaut suivante : `false`. Si défini sur `true`, l'exécution de la règle est déchargée sur un thread différent, laissant ainsi le thread principal disponible pour gérer des requêtes supplémentaires. Une fois le traitement hors connexion terminé, le thread principal revient et finit le traitement du flux de messages. Dans certains cas, la définition de l'option "async" sur `true` améliore les performances du proxy d'API. Cependant, une utilisation excessive de la méthode asynchrone peut nuire aux performances lorsque le nombre de threads est trop important. Pour utiliser un comportement asynchrone dans des proxys d'API, consultez la page Modèle d'objet JavaScript.	`false`	Non

Rattachement de stratégie

L'image suivante montre la séquence d'exécution des flux de proxy d'API :

Comme indiqué ci-dessus :

Les règles sont associées en tant qu'étapes de traitement aux Flux. Le nom de la règle est utilisé pour référencer la stratégie à appliquer en tant qu'étape de traitement. Le format d'un rattachement de stratégies est le suivant :

<Step><Name>MyPolicy</Name></Step>

Les stratégies sont appliquées dans l'ordre dans lequel elles sont associées à un flux. Exemple :

<Step><Name>FirstPolicy</Name></Step>
<Step><Name>SecondPolicy</Name></Step>

Éléments de configuration de rattachement de stratégie

Nom	Description	Par défaut	Requis ?
`Step`
`Name`	Nom de la stratégie à exécuter par cette définition d'étape.	N/A	Oui
`Condition`	Instruction conditionnelle déterminant si la stratégie est appliquée ou non. Si une stratégie est associée à une condition, elle ne s'exécute que si l'instruction conditionnelle est définie sur "true".	N/A	Non

Flux

ProxyEndpoint et TargetEndpoint définissent un pipeline pour le traitement des messages de requête et de réponse. Un pipeline de traitement se compose d'un flux de requête et d'un flux de réponse. Chaque flux de requêtes et chaque flux de réponses sont subdivisés en flux PreFlow, un ou plusieurs flux conditionnels ou nommés facultatifs, et un postFlow.

PreFlow : s'exécute toujours. S'exécute avant les flux conditionnels, le cas échéant.
PostFlow : s'exécute toujours. S'exécute après les flux conditionnels, le cas échéant.

En outre, vous pouvez ajouter un PostClientFlow au point de terminaison du proxy, qui s'exécute une fois la réponse renvoyée à l'application cliente à l'origine de la requête. Seule la règle MessageLogging peut être associée à ce flux. PostClientFlow réduit la latence du proxy d'API et met les informations à disposition pour la journalisation ne faisant pas l'objet de calculs avant que la réponse ne soit renvoyée au client, comme client.sent.start.timestamp et client.sent.end.timestamp. Le flux est utilisé principalement pour mesurer l'intervalle de temps entre les horodatages de début et de fin du message de réponse.

Voici un exemple de flux PostClientFlow avec une stratégie de journalisation des messages.

...
  <PostFlow name="PostFlow">
      <Request/>
      <Response/>
  </PostFlow>
  <PostClientFlow>
      <Request/>
      <Response>
          <Step>
              <Name>Message-Logging-1</Name>
          </Step>
      </Response>
  </PostClientFlow>
  ...

Le pipeline de traitement proxy de l'API exécute les flux dans l'ordre suivant :

Pipeline des requêtes :

PreFlow de requête de proxy
Flux conditionnels de requête de proxy (facultatif)
Post-flux de requête de proxy
PreFlow de requête cible
Flux conditionnels de requête cible (facultatif)
Post-flux de requête cible

Pipeline de réponse :

PreFlow de réponse cible
Flux conditionnels des réponses cibles (facultatif)
Post-flux de réponse cible
PreFlow de réponse proxy
Flux conditionnels de réponse proxy (facultatif)
Post-flux de réponse proxy
Requête post-flux client (facultatif)

Seuls les flux avec des rattachements de stratégies doivent être configurés dans les configurations ProxyEndpoint ou TargetEndpoint. Les flux PreFlow et PostFlow ne doivent être spécifiés que dans une configuration ProxyEndpoint ou TargetEndpoint lorsqu'une stratégie doit être appliquée lors du traitement de PreFlow ou PostFlow.

Contrairement aux flux conditionnels, l'ordre des éléments PreFlow et PostFlow n'est pas important. Le proxy d'API exécute toujours chaque élément au moment approprié dans le pipeline, quel que soit leur emplacement dans la configuration du point de terminaison.

Flux conditionnels

Les points de terminaison du proxy et points de terminaison cibles sont compatibles avec un nombre illimité de flux conditionnels (également appelés flux nommés).

Le proxy d'API teste la condition spécifiée dans le flux conditionnel et, si la condition est remplie, les étapes de traitement du flux conditionnel sont exécutées par le proxy d'API. Si la condition n'est pas remplie, les étapes de traitement du flux conditionnel sont ignorées. Les flux conditionnels sont évalués dans l'ordre défini dans le proxy de l'API et le premier dont la condition est remplie est exécutée.

En définissant des flux conditionnels, vous pouvez appliquer des étapes de traitement dans un proxy d'API en fonction des éléments suivants :

URI de la requête
Verbe HTTP (GET/PUT/POST/DELETE)
Valeur d'un paramètre de requête, d'un en-tête et d'un paramètre de formulaire
Beaucoup d'autres types de conditions

Par exemple, le flux conditionnel suivant spécifie qu'il n'est exécuté que lorsque le chemin de la ressource de requête est /accesstoken. Toute requête entrante avec le chemin /accesstoken entraîne l'exécution de ce flux, ainsi que toutes les règles associées au flux. Si le chemin de la requête n'inclut pas le suffixe /accesstoken, le flux ne s'exécute pas (même si un autre flux conditionnel peut être utilisé).

<Flows>
  <Flow name="TokenEndpoint">
    <Condition>proxy.pathsuffix MatchesPath "/accesstoken"</Condition>
    <Request>
      <Step>
        <Name>GenerateAccessToken</Name>
      </Step>
    </Request> 
  </Flow>
</Flows>

Éléments de configuration de flux

Nom	Description	Par défaut	Requis ?
`Flow`	Pipeline de traitement de requête ou de réponse défini par un point de terminaison du proxy ou un point de terminaison cible
`Name`	Nom unique du flux.	N/A	Oui
`Condition`	Instruction conditionnelle qui évalue une ou plusieurs variables à évaluer sur "vrai" ou "faux". Tous les flux autres que les types PreFlow et PostFlow prédéfinis doivent définir une condition pour leur exécution.	N/A	Oui
`Request`	Pipeline associé au processeur des messages de requête	N/A	Non
`Response`	Pipeline associé au processeur des messages de réponse	N/A	Non

Traitement par étapes

L'ordre séquentiel des flux conditionnels est appliqué par Apigee. Les flux conditionnels s'exécutent de haut en bas. Le premier flux conditionnel dont la condition est évaluée à true est exécuté, et un seul flux conditionnel est exécuté.

Par exemple, dans la configuration de flux suivante, toute requête entrante qui n'inclut pas le suffixe de chemin /first ou /second entraîne l'exécution de la règle ThirdFlow, en appliquant la règle nommée Return404.

<Flows>
  <Flow name="FirstFlow">
    <Condition>proxy.pathsuffix MatchesPath "/first"</Condition>
    <Request>
      <Step><Name>FirstPolicy</Name></Step>
    </Request>
  </Flow>
  <Flow name="SecondFlow">
    <Condition>proxy.pathsuffix MatchesPath "/second"</Condition>
    <Request>
      <Step><Name>FirstPolicy</Name></Step>
      <Step><Name>SecondPolicy</Name></Step>
    </Request>
  </Flow>
  <Flow name="ThirdFlow">
    <Request>
      <Step><Name>Return404</Name></Step>
    </Request>
  </Flow>
</Flows>

Ressources

Les "ressources" (fichiers de ressources à utiliser dans les proxys d'API) sont des scripts, du code et des transformations XSL pouvant être associés aux flux à l'aide de règles. Celles-ci s'affichent dans la section Scripts de l'éditeur de proxy d'API dans l'interface utilisateur d'Apigee.

Pour connaître les types de ressources compatibles, consultez la section Gérer les ressources.

Les ressources peuvent être stockées dans un proxy d'API, un environnement ou une organisation. Dans chaque cas, une ressource est référencée par son nom dans une stratégie. Apigee résout le nom en passant du proxy d'API à l'environnement, au niveau de l'organisation.

Une ressource stockée au niveau de l'organisation peut être référencée par des stratégies dans n'importe quel environnement. Une ressource stockée au niveau de l'environnement peut être référencée par des stratégies dans cet environnement. Une ressource stockée au niveau du proxy d'API ne peut être référencée que par des règles dans ce proxy d'API.