Antimodèle: appeler des appels d'API de gestion à partir d'un proxy d'API

Vous consultez la documentation Apigee Edge.
Accédez à la documentation**Apigee X**. info

Edge dispose d'un puissant utilitaire appelé "API de gestion" 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, des produits d'API, des applications de développement, 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 Edge appelé Serveur de gestion. Ils peuvent être appelés facilement à l'aide d'appels d'API de gestion simples.

Il est parfois nécessaire d'utiliser un ou plusieurs de ces services à partir de proxys d'API lors 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éveloppement, 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 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éveloppement.

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

Antimodèle

Les API de gestion 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. Voici pourquoi :

  • L'utilisation d'API de gestion à 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 sur les serveurs de gestion.
  • Les serveurs de gestion ne font pas partie des composants d'exécution Edge. 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 des 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 d'API de gestion est lancé via le code JavaScript personnalisé pour extraire les informations du mappage clés-valeurs :

var response = httpClient.send('https://api.enterprise.apigee.com/v1/o/org_name/e/env_name/keyvaluemaps/kvm_name')

Si le serveur de gestion n'est pas disponible, le code JavaScript appelant l'API de gestion é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 de gestion 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éveloppement, 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 récupérer des informations à partir 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éveloppement, 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 : 
      <!-- /antipatterns/examples/2-7.xml -->
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 dispose pas d'une règle VerifyAPIKey, vous pouvez accéder aux profils de produits API, d'applications de développement, etc. en utilisant les règles AccessEntity et ExtractVariables policies:
      1. Récupérez le profil de DeveloperApp 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>
      2. Extrayez le appId de DeveloperApp 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>

Documentation complémentaire