Outils de développement

<ph type="x-smartling-placeholder"></ph> Vous consultez la documentation Apigee Edge.
Accédez à la page Documentation sur Apigee X. En savoir plus

En tant que fournisseur de services, vous développez des API qui seront utilisées par les 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 au 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 de navigateur qui vous permet de créer, configurer et gérer Proxys d'API et produits d'API Un sous-ensemble de tâches ne peut être réalisé qu'à l'aide de l'API, .

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

https://apigee.com/edge

http://ms-ip:9000

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

• Créez des proxys d'API en modifiant le code et en traçant les flux de requêtes via vos proxys.
• Créez des produits d'API qui regroupent des proxys pour une exposition aux requêtes des clients.
• Gérer les développeurs et leurs applications
• Configurez vos environnements de test et de production.
• Implémenter des applications JavaScript et Node.js

L'image suivante montre l'éditeur de proxy 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 donnent également accès à des fonctionnalités de bas niveau qui ne sont pas exposées par le 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. Suivre RESTful vous pouvez appeler HTTP GET, POST, PUT et DELETE sur n'importe quelle ressource de l'API.

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

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

Le chemin 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 passez au L'API utilisera le chemin de base suivant:

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

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

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

De nombreuses ressources sont définies par environnement. Deux environnements sont fournis par défaut : prod. 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. Vous pouvez de l'une des manières suivantes:

• OAuth2
• SAML
• Authentification de base (non recommandé)

Apigee vous recommande également 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 taux 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 pris en compte dans cette limite. Tous les appels qui dépassent ces Les limites renvoient un code d'état 429 Too Many Requests.

Conseils d'utilisation des API Edge

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

Abréviation des URL de requête

Lorsque vous créez l'URL de votre demande pour les API Edge, vous pouvez utiliser les éléments suivants abréviations:

• /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 dans 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.

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 dans la documentation fournir des exemples de requêtes API à l'aide de curl, un client HTTP très utilisé. Si vous avez besoin de installez curl, vous pouvez le télécharger depuis http://curl.haxx.se.

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

Mettre en forme les requêtes et 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 est renvoyé 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 sous la forme suivante:

<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 vers xmllint

L'utilitaire acurl n'est pas compatible avec l'en-tête Accept. Vous pouvez ainsi n'obtient 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 le format XML, vous pouvez utiliser xmllint:

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

Lorsque vous effectuez une opération 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 pour Développer, tester et déployer des API : "test" et "prod". Utiliser l'expression "test" pour développer et tester vos API avant de les rendre publiques. Seuls vos développeurs internes ont accès aux API déployés dans l'environnement de test. Déployer vos API sur la "production" pour les rendre publiques pour les développeurs d'applications.

Débogage et test

Apigee fournit un outil de trace qui vous permet de déboguer requête et réponse de bout en bout les flux de données. Les résultats de la trace affichent les en-têtes de requête et de réponse ainsi que les charges utiles, l'exécution de la stratégie, les valeurs des variables et toutes les erreurs qui ont pu se produire pendant le flux.

Points clés à prendre en compte pour le dépannage:

• Codes temporels: utilisez des codes temporels pour voir le temps nécessaire à l'exécution de chaque étape. La comparaison des horodatages vous permet d'isoler les stratégies dont l'exécution prend le plus de temps ralentissent vos appels d'API.
• Chemin de base: en vérifiant le chemin de base, vous pouvez vous assurer qu'une stratégie est le routage du message vers le serveur approprié.
• Résultats de l'exécution de la stratégie: ces résultats vous permettent de voir si le message est soient modifiés comme prévu, par exemple si le message est en cours de transformation de XML en JSON, ou si le message est mis en cache.

La figure suivante illustre les résultats de trace:

Chaque session Trace se compose des grandes étapes suivantes:

• Requête d'origine reçue du client: affiche le verbe et le chemin d'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.
• Request sent to your backend service (Requête envoyée à votre service de backend) : affiche le message de requête envoyé à 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ées par le service de backend.
• Final response sent to client (Réponse finale envoyée au client) : message de réponse renvoyé au qui demande l'application cliente une fois le flux de réponse exécuté.