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 | EdgePour accéder à l'interface utilisateur Edge pour Edge for Private Cloud, utilisez l'URL suivante: http://ms-ip:9000 Où 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:
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:
- OAuth2
- SAML
- Basic Auth (authentification de base) (non recommandé)
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:
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é.