Cette page a été traduite par l'API Cloud Translation.

Envoyer des requêtes API directes aux routeurs ou aux processeurs de messages

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

Introduction

Lors du dépannage, vous pouvez exécuter des API directement sur des composants Apigee tels qu'un routeur ou un processeur de messages. Vous pouvez par exemple effectuer cette opération pour effectuer les opérations suivantes:

Résolvez les problèmes intermittents liés à certaines requêtes API qui renvoient à un problème avec un composant Apigee particulier (routeur/processeur de messages).
Vous pouvez collecter plus d'informations de diagnostic en activant le mode débogage sur une instance spécifique d'un composant Apigee.
Excluez que le problème soit causé par un composant Apigee spécifique.
Déterminez si des opérations telles que la création ou le redémarrage d'une instance ont l'impact souhaité.

Conditions préalables

Accès direct au routeur ou aux composants du processeur de messages pour lesquels les requêtes API doivent être exécutées.
L'outil cURL doit être installé sur l'instance spécifique du composant.
Requête API que vous souhaitez tester au format cURL.

Par exemple, voici une commande curl que vous pourriez utiliser pour envoyer une requête à un proxy d'API à partir de votre machine locale:
```
curl https://myorg-test.mycompany.com/v1/customers -H 'Authorization: Bearer AxLqyU09GA10lrAiVRQCGXzMi9W2'
```
Remarque :Vous pouvez identifier des problèmes tels qu'un déploiement manquant avec une boucle, même partielle. Tant que le trafic est envoyé au proxy approprié pour lequel seuls l'hôte et le chemin de base appropriés sont nécessaires, vous pouvez exécuter des tests utiles sans avoir les en-têtes nécessaires pour obtenir une réponse positive, comme un en-tête d'autorisation. Dans ce cas, l'exemple ci-dessus sans en-tête constitue un scénario de test valide:
```
curl https://myorg-test.mycompany.com/v1/customers
```
.

Comment exécuter des requêtes API directement sur des routeurs Apigee

Scénario 1: Requêtes API adressées à un alias d'hôte pointant vers des routeurs

Si l'entrée DNS de l'alias d'hôte est configurée pour pointer vers les routeurs Apigee Edge (en d'autres termes, il n'existe pas d'Elastic Load Balancer), vous pouvez utiliser les commandes curl suivantes pour envoyer les requêtes API directement à un routeur:

Hôte virtuel configuré pour une communication non sécurisée via le port 80

curl -v --resolve HOST_ALIAS:80:127.0.0.1 http://HOST_ALIAS/PROXY_BASE_PATH/ -H 'HEADER: VALUE'

Exemple :

curl -v --resolve myorg-test.mycompany.com:80:127.0.0.1 http://myorg-test.mycompany.com/v1/customers -H 'Authorization: Bearer AxLqyU09GA10lrAiVRQCGXzMi9W2'

L'hôte virtuel est configuré pour terminer le protocole SSL sur le port 443 du routeur

curl -v --resolve HOST_ALIAS:443:127.0.0.1 https://HOST_ALIAS/PROXY_BASE_PATH/ -H 'HEADER: VALUE'

Exemple :

curl -v --resolve myorg-test.mycompany.com:443:127.0.0.1 https://myorg-test.mycompany.com/v1/customers -H 'Authorization: Bearer AxLqyU09GA10lrAiVRQCGXzMi9W2'

Scénario 2: Requêtes API adressées à un alias d'hôte pointant vers ELB

Si l'entrée DNS de l'alias d'hôte est configurée pour pointer vers un équilibreur de charge Elastic Load Balancer (ELB), vous pouvez utiliser les commandes curl suivantes pour envoyer les requêtes API directement à un routeur:

Hôte virtuel configuré pour une communication non sécurisée via le port 80

curl -v --resolve HOST_ALIAS:80:127.0.0.1 http://HOST_ALIAS/PROXY_BASE_PATH/ -H 'HEADER: VALUE'

Exemple :

curl -v --resolve myorg-test.mycompany.com:80:127.0.0.1 http://myorg-test.mycompany.com/v1/customers -H 'Authorization: Bearer AxLqyU09GA10lrAiVRQCGXzMi9W2'

Un hôte virtuel configuré pour un port élevé et SSL se terminant sur un équilibreur de charge devant le routeur Apigee

curl -v --resolve HOST_ALIAS:PORT_NUMBER:127.0.0.1 http:/HOST_ALIAS:PORT_NUMBER/PROXY_BASE_PATH/ -H 'HEADER: VALUE'

Exemple :

curl -v --resolve myorg-test.mycompany.com:19001:127.0.0.1 http://myorg-test.mycompany.com/v1/customers -H 'authorization: Bearer AxLqyU09GA10lrAiVRQCGXzMi9W2'

Hôte virtuel configuré pour un port élevé et SSL se terminant sur le routeur Apigee

En d'autres termes, l'équilibreur de charge est configuré pour utiliser le passthrough TCP vers le routeur Apigee.

curl -v --resolve HOST_ALIAS:PORT_NUMBER:127.0.0.1 https:/HOST_ALIAS:PORT_NUMBER/PROXY_BASE_PATH/ -H 'HEADER: VALUE'

Exemple :

curl -v --resolve myorg-test.mycompany.com:19001:127.0.0.1 https://myorg-test.mycompany.com/v1/customers -H 'authorization: Bearer AxLqyU09GA10lrAiVRQCGXzMi9W2'

Exécuter des requêtes directement sur les processeurs de messages Apigee

Scénario 1: requête API adressée au processeur de messages via le port par défaut 8998

Le port par défaut sur lequel le processeur de messages écoute le trafic provenant du routeur Apigee est le 8998. Par conséquent, dans tous les cas où ce port n'a pas été modifié, le trafic doit être envoyé directement à ce port sur une instance de processeur de messages spécifique, comme dans l'exemple suivant. La requête curl doit être envoyée à l'URL http://INTERNAL_IP_OF_MP:8998 avec l'en-tête X-Apigee.Host avec la valeur hostname, y compris le port utilisé dans les hôtes virtuels, comme indiqué dans les trois exemples suivants:

L'hôte virtuel est configuré pour la terminaison SSL sur le routeur

curl -v http://INTERNAL_IP_OF_MP:8998/PROXY_BASE_PATH/ -H 'HEADER: VALUE' -H 'X-Apigee.Host: HOST_ALIAS:443'

Exemple :

curl -v http://10.10.53.115:8998/v1/customers -H 'Authorization: Bearer AxLqyU09GA10lrAiVRQCGXzMi9W2' -H 'X-Apigee.Host: myorg-test.mycompany.com:443'

L'hôte virtuel est configuré pour un "port élevé" et la terminaison SSL s'effectue sur un équilibreur de charge OU sur un routeur Apigee:

curl -v http://INTERNAL_IP_OF_MP:8998/PROXY_BASE_PATH/ -H 'HEADER: VALUE' -H 'X-Apigee.Host: HOST_ALIAS:PORT_NUMBER'

Exemple :

curl -v http://10.10.53.115:8998/v1/customers -H 'Authorization: Bearer AxLqyU09GA10lrAiVRQCGXzMi9W2' -H 'X-Apigee.Host: myorg-test.mycompany.com:19001'

L'hôte virtuel est configuré sur le port HTTP 80 par défaut

curl -v http://INTERNAL_IP_OF_MP:8998/PROXY_BASE_PATH/ -H 'HEADER: VALUE' -H 'X-Apigee.Host: HOST_ALIAS:80'

Exemple :

curl -v http://10.10.53.115:8998/v1/customers -H 'Authorization: Bearer AxLqyU09GA10lrAiVRQCGXzMi9W2' -H 'X-Apigee.Host: myorg-test.mycompany.com:80'

Scénario 2: requête API adressée au processeur de messages via le port SSL 8443

Il est possible de configurer la communication SSL entre le routeur et le processeur de messages. Les exemples suivants utilisent le port 8443, port suggéré par la documentation Apigee.

L'hôte virtuel est configuré pour la terminaison SSL sur le routeur

curl -v -k https://INTERNAL_IP_OF_MP:8443/PROXY_BASE_PATH/ -H 'HEADER: VALUE' -H 'X-Apigee.Host: HOST_ALIAS:443'

Exemple :

curl -v https://10.10.53.115:8443/v1/customers -H 'Authorization: Bearer AxLqyU09GA10lrAiVRQCGXzMi9W2' -H 'X-Apigee.Host: myorg-test.mycompany.com:80'

L'hôte virtuel est configuré pour la terminaison SSL sur un équilibreur de charge, et le trafic est transféré vers un port de haut niveau vers le routeur
```
curl -v https://INTERNAL_IP_OF_MP:8443/PROXY_BASE_PATH/ -H 'HEADER: VALUE' -H 'X-Apigee.Host: HOST_ALIAS:PORT_NUMBER'
```
Exemple :
```
curl -v https://10.10.53.115:8443/v1/customers -H 'Authorization: Bearer AxLqyU09GA10lrAiVRQCGXzMi9W2' -H 'X-Apigee.Host: myorg-test.mycompany.com:19001'
```
Remarque :La même commande curl est utilisée pour les requêtes qui utilisent un protocole SSL mutuel et ne pourrait donc pas être testée sans certificat client.