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

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

<ph type="x-smartling-placeholder"></ph> Vous consultez la documentation Apigee Edge.
Accédez à la page Documentation sur 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. Par exemple, vous pouvez effectuer cette opération pour:

Débogue les problèmes intermittents liés à certaines requêtes API qui pointent vers un problème lié à un composant Apigee particulier (routeur/processeur de messages).
Obtenez plus d'informations de diagnostic en activant le mode débogage sur une instance spécifique d'un composant Apigee.
Déterminez si le problème est causé par un composant Apigee spécifique.
Déterminez si les opérations telles que la création d'une nouvelle instance ou le redémarrage de l'instance ont l'impact souhaité.

Prérequis

Accès direct aux composants du routeur ou du processeur de messages sur 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 pouvez 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 que des déploiements manquants, même avec une curl 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 d'en-têtes qui seraient nécessaires pour obtenir une réponse positive, comme un en-tête Authorization. Dans ce cas, l'exemple ci-dessus, sans l'en-tête, constitue un scénario de test valide:
```
curl https://myorg-test.mycompany.com/v1/customers
```

Exécuter des requêtes API directement sur les 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'y a pas d'é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'

L'hôte virtuel est configuré pour interrompre 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 des ELB

Si l'entrée DNS de l'alias d'hôte est configurée pour pointer vers un équilibreur de charge ELB (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'

Hôte virtuel configuré pour un port élevé avec terminaison SSL 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 la terminaison SSL 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 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 incluant le port utilisé dans les hôtes virtuels, comme illustré 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 a lieu 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, le port suggéré dans 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 le routeur sur un port élevé
```
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 utilisant l'authentification SSL mutuelle et ne peut donc pas être testée sans certificat client.