Outils de développement

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

En tant que fournisseur de services, vous développez des API destinées à être utilisées par des 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 à des 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 que vous pouvez utiliser pour créer, configurer et gérer des proxys d'API et des produits d'API. Un sous-ensemble de tâches ne peut être effectué qu'à l'aide de l'API, aussi.

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

https://apigee.com/edge

http://ms-ip:9000

L'interface utilisateur Edge vous permet de :

• créer des proxys d'API en modifiant le code et en suivant les flux de requêtes via vos proxys ;
• créer des produits d'API qui regroupent des proxys pour les exposer aux requêtes client ;
• gérer les développeurs et les applications développeur ;
• configurer vos environnements de test et de production ;
• implémenter 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 vos ressources d'API. Les API permettent également d'accéder à des fonctionnalités de bas niveau qui ne sont pas exposées par l' interface utilisateur.

Les points de terminaison d'API utilisent 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. En suivant les 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 de base de l'API Edge path

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

• Un chemin de base qui inclut 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 utilisera le chemin de base suivant :

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

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

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

De nombreuses ressources sont limitées par l'environnement. Deux environnements sont fournis par défaut : test et prod. Par exemple, les caches sont limités par l'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. Vous pouvez le faire de l'une des manières suivantes :

• OAuth2
• SAML
• Authentification de base (déconseillée)

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

Limites de l'API Edge

Chaque organisation est limitée aux débits d'appels d'API Edge suivants :

• 10 000 appels par minute pour les organisations disposant d'un forfait payant
• 600 appels par minute pour les organisations d'essai

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

Conseils pour utiliser les API Edge

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

Abréger les URL de requête

Lorsque vous créez votre URL de requête pour 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, vous devez abréger tous les éléments du chemin, comme indiqué ci-dessus et illustré dans l'exemple suivant, ou aucun. L'utilisation d'éléments complets et abrégés dans le même chemin entraînera une erreur.

Par 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

Utilisez un client HTTP pour envoyer des requêtes à l'API. De nombreux exemples de la documentation fournissent des exemples de requêtes d'API à l'aide de curl, un client HTTP largement utilisé. Si vous devez installer curl, vous pouvez le télécharger à l'adresse http://curl.haxx.se.

Les appels à l'API sont compatibles avec 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 sera 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 page devrait ressembler à l'exemple ci-dessous :

<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 que des réponses au format JSON avec acurl.

Pour 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 XML, vous pouvez utiliser xmllint :

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

Lorsque vous envoyez des charges utiles XML avec POST ou PUT, 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

Par défaut, chaque organisation qui utilise Apigee Edge dispose d'au moins deux environnements qu'elle peut utiliser pour développer, tester et déployer des API : "test" et "prod". Utilisez l'environnement "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 "prod" pour les rendre publiques 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 du traçage affichent les en-têtes et les charges utiles des requêtes et des réponses, l'exécution des règles, les valeurs des variables et toutes 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 codes temporels pour voir combien de temps prend chaque étape. La comparaison des codes temporels 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 de base, vous pouvez vous assurer qu'une règle achemine le message vers le serveur approprié.
• Résultats de l'exécution des règles : ces résultats vous permettent de voir si le message est modifié comme prévu, par exemple s'il est transformé de XML en JSON ou s'il est mis en cache.

La figure suivante montre les résultats du traçage :

Chaque session de traçage est divisée en plusieurs étapes principales :

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