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

Vous consultez la documentation d'Apigee Edge.
Accédez à la page Documentation sur 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.
  • 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éveloppeur, des développeurs, des clés client, etc.
  • La récupération d'informations sur ces entités

Ces services sont accessibles via un composant appelé Management Server (Serveur de gestion) dans le plate-forme Apigee Edge. Ces services peuvent être appelés facilement à l'aide d'une API de gestion simple. appels.

Il est parfois nécessaire d'utiliser un ou plusieurs de ces services à partir de proxys d'API lors de l'exécution. C'est car 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, ou dans 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 exécuter une logique d'exécution dans le flux des proxys d'API. Voici pourquoi :

  • Utilisation des API de gestion pour accéder aux informations sur les entités telles que KeyValueMaps, OAuth Les jetons d'accès ou à toute autre fin provenant des proxys d'API entraînent une dépendance sur la gestion Serveurs.
  • Les serveurs de gestion ne font pas partie du composant Edge Runtime, par conséquent, ils peuvent ne pas être à disponibilité élevée.
  • 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 à l'API de gestion est lancé via le code JavaScript personnalisé pour extraire 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 appelant l'API de gestion l'appel é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é. comme KVM chiffré.
  • Incidences sur les performances dues au recours au service de gestion sur le réseau.
  • Risque de ne pas voir immédiatement les valeurs mises à jour en raison de l'expiration plus longue du cache dans la gestion serveurs.

Bonne pratique

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

  • Utilisez une règle KeyValueMapOperations pour accéder aux informations de KeyValueMaps. Voici un exemple de code qui montre comment récupérer des informations à partir du 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>
  • 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 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 comporte pas de règle VerifyAPIKey, vous pouvez accéder aux profils de produits API, d'applications de développement, etc. à l'aide des règles AccessEntity et ExtractVariables :
      1. Récupérez le profil de DeveloperApp à l'aide de 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 à l'aide de 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