Antimodèle : lancer des appels d'API Apigee à partir d'un proxy d'API

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

Apigee dispose d'un puissant utilitaire appelé API Apigee qui propose des services tels que :

Le déploiement ou l'annulation du déploiement des proxys d'API
La configuration des hôtes virtuels, keystores et truststores, etc.
La création, la suppression et/ou la mise à jour d'entités telles que des mappages clés-valeurs (KVM - Key Value Maps), des produits d'API, des applications de développeur, des développeurs, des clés client, etc.
La récupération d'informations sur ces entités

Ces services sont accessibles à travers un composant de la plate-forme Apigee appelé Serveur de gestion. Ces services peuvent être appelés facilement grâce à de simples appels d'API.

Il est parfois nécessaire d'utiliser un ou plusieurs de ces services à partir de proxys d'API au moment de l'exécution. En effet, les entités telles que les mappages clés-valeurs, les jetons d'accès OAuth, les produits d'API, les applications de développeur, les développeurs, les clés client, etc. contiennent des informations utiles sous forme de paires clé/valeur ou d'attributs personnalisés qui font partie de son profil.

Par exemple, vous pouvez stocker les informations suivantes dans des objets KeyValueMap pour les sécuriser davantage et faciliter leur accès au moment de l'exécution :

URL de cibles backend
Propriétés des environnements
Identifiants de sécurité des systèmes backend ou tiers

De la même manière, vous pouvez souhaiter obtenir la liste des produits d'API ou l'adresse e-mail du développeur au moment de l'exécution. Ces informations seront disponibles dans le profil des applications de développeur.

Toutes ces informations peuvent être utilisées efficacement lors de l'exécution pour permettre aux règles ou au code personnalisé d'Apigee d'adopter un comportement dynamique.

Antimodèle

Les API Apigee sont recommandées et utiles pour les tâches d'administration. Elles ne doivent pas être utilisées pour exercer une logique d'exécution dans le flux des proxys d'API, et ce, pour les raisons suivantes :

L'utilisation d'API Apigee à partir de proxys d'API pour accéder à des informations sur des entités telles que les mappages clés-valeurs, les jetons d'accès OAuth, ou pour tout autre but, induit une dépendance aux serveurs de gestion.
Les serveurs de gestion ne font pas partie des composants d'exécution Apigee. Ils ne sont donc pas forcément dotés d'une haute disponibilité.
Les serveur de gestion ne sont pas non plus forcément provisionnés au sein du même réseau ou du même centre de données. Il peuvent donc induire des latences réseau au moment de l'exécution.
Les entrées sur les serveurs de gestion sont mises en cache pendant une période plus longue. Par conséquent, il est possible que les données les plus récentes ne soient pas immédiatement visibles dans les proxys d'API si des écritures et lectures sont effectuées dans un court délai.
Cela induit davantage de sauts de réseau lors de l'exécution.

Dans l'exemple de code ci-dessous, l'appel à l'API Apigee est lancé via le code JavaScript personnalisé pour extraire les informations du mappage clés-valeurs :

var response = httpClient.send('https://apigee.googleapis.com/v1/organizations/$ORG/environments/$ENV/keyvaluemaps')

Si le serveur de gestion n'est pas disponible, le code JavaScript appelant l'API Apigee échoue. Cela entraîne l'échec de la requête API.

Impact

Introduit des dépendances supplémentaires sur les serveurs de gestion lors de l'exécution. Toute défaillance des serveurs de gestion aura une incidence sur les appels d'API.
Les identifiants utilisateur des API Apigee doivent être stockés localement ou dans un espace de stockage sécurisé, tel qu'une KVM chiffrée.
Incidences sur les performances dues au recours au service de gestion sur le réseau.
Il est possible que les valeurs mises à jour ne soient pas immédiatement visibles en raison de l'expiration du cache, qui prend plus de temps sur les serveurs de gestion.

Bonne pratique

Lors de l'exécution, il existe des moyens plus efficaces de récupérer des informations à partir d'entités telles que les mappages clés-valeurs, les produits d'API, les applications de développeur, les développeurs, les clés client, etc. Voici quelques exemples :

Utilisez une règle KeyValueMapOperations pour accéder aux informations des mappages clés-valeurs. Voici un exemple de code qui montre comment extraire les informations du mappage clés-valeurs :

<!-- /antipatterns/examples/2-6.xml -->
<KeyValueMapOperations mapIdentifier="urlMap" async="false"
    continueOnError="false" enabled="true" name="GetURLKVM">
  <DisplayName>GetURLKVM</DisplayName>
  <ExpiryTimeInSecs>86400</ExpiryTimeInSecs>
  <Scope>environment</Scope>
  <Get assignTo="urlHosti" index="2">
    <Key>
      <Parameter>urlHost_1</Parameter>
    </Key>
  </Get>
</KeyValueMapOperations>

Dans le proxy d'API, pour accéder à des informations sur les produits d'API, les applications de développeur, les développeurs, les clés client, etc. effectuez l'une des opérations suivantes :

Si votre flux de proxy d'API dispose d'une règle VerifyAPIKey, vous pouvez accéder aux informations à l'aide des variables de flux renseignées dans le cadre de cette règle. Voici un exemple de code qui montre comment récupérer le nom et les informations de création d'une application de développement à l'aide de JavaScript :
```

print("Application Name ", context.getVariable(""verifyapikey. VerifyAPIKey.app.name"));
print("Created by:", context.getVariable("verifyapikey. VerifyAPIKey.app.created_by"));
```

Si votre flux de proxy d'API ne comporte pas de règle VerifyAPIKey, vous pouvez accéder aux profils de produits d'API, d'applications de développeur, etc. en utilisant les règles AccessEntity et ExtractVariables :

Récupérez le profil de l'application de développeur avec la règle AccessEntity :

<!-- /antipatterns/examples/2-8.xml -->
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<AccessEntity async="false" continueOnError="false" enabled="true" name="GetDeveloperApp">
  <DisplayName>GetDeveloperApp</DisplayName>
  <EntityType value="app"></EntityType>
  <EntityIdentifier ref="developer.app.name" type="appname"/>
  <SecondaryIdentifier ref="developer.id" type="developerid"/>
</AccessEntity>

Extrayez les données appId de l'application de développeur avec la règle ExtractVariables :

<!-- /antipatterns/examples/2-9.xml -->
<ExtractVariables name="Extract-Developer App-Info">
  <!--
    The source element points to the variable populated by AccessEntity policy.
    The format is <policy-type>.<policy-name>
    In this case, the variable contains the whole developer profile.
  -->
  <Source>AccessEntity.GetDeveloperApp"</Source>
  <VariablePrefix>developerapp</VariablePrefix>
  <XMLPayload>
    <Variable name="appld" type="string">
      <!-- You parse elements from the developer profile using XPath. -->
      <XPath>/App/AppId</XPath>
    </Variable>
  </XMLPayload>
</ExtractVariables>

Antimodèle : lancer des appels d'API Apigee à partir d'un proxy d'API

Antimodèle

Impact

Bonne pratique

Documentation complémentaire