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

Vous consultez la documentation d'Apigee Edge.
Consultez la documentation Apigee X. en savoir plus

Edge dispose d'un puissant utilitaire appelé "API de gestion" qui offre 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.
  • Création, suppression et/ou mise à jour d'entités telles que KeyValueMaps, produits d'API, applications de développement, développeurs, clés client, etc.
  • La récupération d'informations sur ces entités

Ces services sont rendus accessibles via un composant appelé serveur de gestion sur la plate-forme Apigee Edge. Ces services peuvent être appelés facilement à l'aide de simples appels d'API de gestion.

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 KeyValueMaps, 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 la forme de paires clé-valeur, d'attributs personnalisés ou dans leur 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 même, vous pouvez 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 au moment de l'exécution pour permettre un comportement dynamique dans les règles ou du code personnalisé dans Apigee Edge.

Antimodèle

Les API de gestion sont privilégiées et utiles pour les tâches administratives et ne doivent pas être utilisées pour exécuter une logique d'exécution dans le flux de proxys d'API. Voici pourquoi :

  • L'utilisation d'API de gestion pour accéder à des informations sur les entités telles que KeyValueMaps, les jetons d'accès OAuth ou, pour toute autre fin, à partir des proxys d'API entraîne une dépendance aux serveurs de gestion.
  • Les serveurs de gestion ne font pas partie du composant d'exécution Edge et peuvent donc ne pas être hautement disponibles.
  • 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 effectué via le code JavaScript personnalisé afin de récupérer les informations du KeyValueMap:

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

Si le serveur de gestion est indisponible, le code JavaScript qui appelle l'appel de 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 pour les API de gestion doivent être stockés localement ou dans un magasin sécurisé tel que KVM chiffré.
  • Incidences sur les performances dues au recours au service de gestion sur le réseau.
  • Il est possible que les valeurs mises à jour ne s'affichent pas immédiatement en raison d'un délai d'expiration plus long du cache dans les serveurs de gestion.

Bonne pratique

Il existe des moyens plus efficaces de récupérer des informations à partir d'entités telles que KeyValueMaps, les produits d'API, les applications pour développeurs, les développeurs, les clés client, etc. au moment de l'exécution. Voici quelques exemples :

  • Utilisez une règle KeyValueMapOperations pour accéder aux informations de KeyValueMap. Voici un exemple de code qui montre comment récupérer des informations à partir de KeyValueMap : 
    <!-- /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>
  • Pour accéder à des informations sur les produits d'API, les applications de développeur, les développeurs, les clés client, etc. dans le proxy d'API, vous pouvez effectuer 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 "create_by" d'une application de développeur à 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 proxy d'API ne dispose pas d'une règle VerifyAPIKey, vous pouvez accéder aux profils de produits d'API, d'applications de développeur, etc. à l'aide des règles d'entité d'accès et d'extraction de variables :
      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 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>

Complément d'informations