Outils de développement

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

En tant que fournisseur de services, vous développez des API destinées aux applications clientes. Pour créer, configurer et gérer des proxys d'API et des produits d'API, vous pouvez utiliser l'interface utilisateur ou envoyer des requêtes HTTP aux API pour accéder aux services RESTful, comme décrit dans les sections suivantes.

Utiliser l'interface utilisateur Edge

L'interface utilisateur Apigee Edge est un outil basé sur un navigateur qui vous permet de créer, configurer et gérer des proxys d'API et des produits d'API. De plus, un sous-ensemble de tâches ne peut être effectué qu'à l'aide de l'API.

Le tableau suivant décrit comment accéder à l'interface utilisateur Edge:

Produit Nom de l'interface utilisateur URL d'accès
Périphérie Interface utilisateur périphérique

Pour accéder à l'interface utilisateur Edge, utilisez l'URL suivante:

https://apigee.com/edge

Pour accéder à un tutoriel sur l'utilisation de l'interface utilisateur Edge, consultez la section Créer votre premier proxy d'API.

Edge pour le cloud privé Interface utilisateur classique de Edge

Pour accéder à l'interface utilisateur Edge pour Edge for Private Cloud, utilisez l'URL suivante:

http://ms-ip:9000

ms-ip correspond à l'adresse IP ou au nom DNS du nœud du serveur de gestion.

À l'aide de l'interface utilisateur Edge, vous pouvez:

  • Créez des proxys d'API en modifiant le code et en suivant les flux de requêtes dans vos proxys.
  • Créez des produits d'API qui regroupent les proxys pour l'exposition aux requêtes des clients.
  • Gérez les développeurs et leurs applications.
  • Configurez vos environnements de test et de production.
  • Implémentez des applications JavaScript et Node.js.

L'image suivante montre l'éditeur de proxys d'API dans l'interface utilisateur que vous pouvez utiliser pour créer et configurer un proxy d'API:

Affiche l'onglet Développement sélectionné dans l'éditeur de proxy d'API de l'interface utilisateur Edge.

Utiliser l'API Edge

Vous pouvez utiliser l'API Edge pour gérer les ressources de vos API. Les API permettent également d'accéder à des fonctionnalités de bas niveau qui ne sont pas exposées par l'UI.

Les points de terminaison de l'API récupèrent souvent des données contenant des informations de configuration et vous obligent à transmettre des informations d'authentification, telles que le nom d'utilisateur et le mot de passe, pour y accéder. Conformément aux principes RESTful, vous pouvez appeler les méthodes HTTP GET, POST, PUT et DELETE sur n'importe quelle ressource d'API.

Pour obtenir la liste complète des API Apigee Edge, consultez la documentation de référence de l'API Apigee Edge.

Comprendre le chemin d'accès de base de l'API Edge

Le chemin d'accès que vous utiliserez dans les requêtes API concatène les éléments suivants:

  • Un chemin d'accès de base incluant le nom de votre organisation Par exemple : https://api.enterprise.apigee.com/v1/organizations/org_name.
  • Un point de terminaison qui pointe vers la ressource Edge à laquelle vous accédez.

Par exemple, si le nom de votre organisation est apibuilders, chaque appel que vous effectuez à l'API utilise le chemin de base suivant:

https://api.enterprise.apigee.com/v1/organizations/apibuilders

Pour récupérer une liste de proxys d'API dans votre organisation, vous devez appeler GET sur:

https://api.enterprise.apigee.com/v1/organizations/apibuilders/apis

De nombreuses ressources sont limitées par environnement. Deux environnements sont fournis par défaut: test et production. Par exemple, les caches sont limités par environnement. Un cache partagé appelé "mycache" est inclus par défaut dans chaque environnement.

Vous pouvez répertorier les caches en appelant GET sur la ressource de cache comme suit:

https://api.enterprise.apigee.com/v1/organizations/apibuilders/environments/test/caches
https://api.enterprise.apigee.com/v1/organizations/apibuilders/environments/prod/caches

Authentifier l'accès

Vous devez vous authentifier auprès du serveur d'API lorsque vous appelez les API. Pour ce faire, procédez de l'une des manières suivantes:

En outre, Apigee vous recommande d'utiliser l'authentification à deux facteurs, comme décrit dans la section Activer l'authentification à deux facteurs pour votre compte Apigee.

Limites de l'API Edge

Chaque organisation est limitée aux tarifs d'appel de l'API Edge suivants:

  • 10 000 appels par minute pour les organisations ayant souscrit un forfait payant
  • 600 appels par minute pour les organisations bénéficiant d'un essai

Les codes d'état HTTP 401 et 403 ne sont pas comptabilisés dans cette limite. Tous les appels qui dépassent ces limites renvoient un code d'état 429 Too Many Requests.

Conseils pour travailler avec les API Edge

Cette section décrit certaines techniques qui facilitent l'utilisation des API Edge.

Abrégation des URL de demande

Lorsque vous créez votre URL de requête vers les API Edge, vous pouvez utiliser les abréviations suivantes:

  • /e = /environments
  • /o = /organizations
  • /r = /revisions

Si vous utilisez des abréviations, vous devez les utiliser de manière cohérente. Autrement dit, abrégez tous les éléments du chemin, comme indiqué ci-dessus et illustré dans l'exemple suivant, ou aucun. Si vous utilisez à la fois des éléments complets et des éléments abrégés dans le même chemin d'accès, cela entraînera une erreur.

Exemple :

THIS:
https://api.enterprise.apigee.com/v1/organizations/ahamilton-eval/environments/prod/apis/helloworld/revisions/1/deployments
CAN BE MUCH SHORTER:
https://api.enterprise.apigee.com/v1/o/ahamilton-eval/e/prod/apis/helloworld/r/1/deployments

Exécuter des commandes curl

Utiliser un client HTTP pour envoyer des requêtes à l'API La documentation contient de nombreux exemples de requêtes API utilisant curl, un client HTTP couramment utilisé. Si vous devez installer curl, vous pouvez le télécharger depuis http://curl.haxx.se.

Les appels de l'API acceptent la compression gzip sur les réponses. Si vous définissez 'Accept-Encoding: gzip, deflate' dans vos appels d'API, toute réponse supérieure à 1 024 octets est renvoyée au format gzip.

Mettre en forme les requêtes et les réponses XML et JSON

L'API Edge renvoie les données au format JSON par défaut. Pour de nombreuses requêtes, vous pouvez obtenir la réponse renvoyée au format XML. Pour ce faire, définissez l'en-tête de requête Accept sur application/xml, comme le montre l'exemple suivant:

curl -H "Authorization: Bearer `get_token`" \
  -H "Accept: application/xml" \
  https://api.enterprise.apigee.com/v1/organizations/ahamilton-eval/apis/helloworld/revisions/1/policies/ \
  | xmllint --format -

La réponse doit se présenter comme suit:

<List>
  <Item>SOAP-Message-Validation-1</Item>
  <Item>Spike-Arrest-1</Item>
  <Item>XML-to-JSON-1</Item>
</List>

Notez que cet exemple utilise prettyprint pour afficher les résultats en redirigeant la réponse via xmllint.

L'utilitaire acurl n'est pas compatible avec l'en-tête Accept. Par conséquent, vous ne pouvez obtenir des réponses au format JSON qu'avec acurl.

Si vous souhaitez utiliser prettyprint pour une réponse JSON, vous pouvez utiliser la bibliothèque Python json.tool:

curl https://api.enterprise.apigee.com/v1/organizations/ahamilton-eval/apis/helloworld/revisions/1/policies/ \
  -H "Accept: application/json" \
  -H "Authorization: Bearer `get_token`" \
  | python -m json.tool

Voici un exemple de réponse :

[
  "SOAP-Message-Validation-1",
  "Spike-Arrest-1",
  "XML-to-JSON-1"
]

Pour le format XML, vous pouvez utiliser xmllint:

curl https://ahamilton-eval-test.apigee.net/getstarted -u email_address | xmllint --format -

Lorsque vous utilisez la méthode POST ou PUT pour des charges utiles en XML, utilisez l'en-tête HTTP Content-type:

acurl -H "Content-type:text/xml" -X POST -d \
'<XMLPayload>
 </XMLPayload> ' \
https://api.enterprise.apigee.com/v1/organizations/apifactory/apis -u email_address

Environnements de déploiement

Chaque organisation qui utilise Apigee Edge par défaut dispose d'au moins deux environnements permettant de développer, de tester et de déployer des API: "test" et "prod". Utilisez l'environnement de "test" pour développer et tester vos API avant de les rendre publiques. Seuls vos développeurs internes peuvent accéder aux API déployées dans l'environnement de test. Déployez vos API dans l'environnement de production pour les rendre accessibles au public auprès des développeurs d'applications.

Débogage et test

Apigee fournit un outil de traçage qui vous permet de déboguer les flux de requêtes et de réponses de bout en bout. Les résultats de la trace affichent les en-têtes de requête et de réponse et les charges utiles, l'exécution de la stratégie, les valeurs de variable et les erreurs qui ont pu se produire pendant le flux.

Points de données clés à utiliser pour le dépannage:

  • Codes temporels: utilisez des horodatages pour déterminer le temps d'exécution de chaque étape. La comparaison des horodatages vous permet d'isoler les règles dont l'exécution prend le plus de temps et qui ralentissent vos appels d'API.
  • Chemin de base: en vérifiant le chemin d'accès de base, vous pouvez vous assurer qu'une règle achemine le message vers le serveur approprié.
  • Résultats de l'exécution de la règle: ces résultats vous permettent de voir si le message est modifié comme prévu, par exemple s'il est transformé du format XML en JSON ou s'il est mis en cache.

La figure suivante montre les résultats de la trace:

Affiche l&#39;onglet Trace sélectionné dans l&#39;éditeur de proxy d&#39;API de l&#39;interface utilisateur Edge.

Chaque session Trace comprend les principales étapes suivantes:

  • Requête initiale reçue du client: affiche le verbe et le chemin d'URI de la requête à partir de l'application cliente, des en-têtes, des données du corps et des paramètres de requête.
  • Request sent to your backend service (Requête envoyée au service de backend) : affiche le message de requête envoyé au service de backend par le proxy d'API.
  • Réponse renvoyée par le service de backend: affiche les en-têtes de réponse et la charge utile renvoyés par le service de backend.
  • Réponse finale envoyée au client:message de réponse renvoyé à l'application cliente à l'origine de la demande une fois le flux de réponse exécuté.