Google verwendet KI-Technologie, um Inhalte in Ihre bevorzugte Sprache zu übersetzen. KI-Übersetzungen können Fehler enthalten.

Direkte API-Anfragen an Router oder Nachrichtenprozessoren senden

Sie lesen gerade die Dokumentation zu Apigee Edge.
Apigee X-Dokumentation aufrufen. info

Einführung

Bei der Fehlerbehebung kann es sinnvoll sein, APIs direkt für Apigee-Komponenten wie einen Router oder Message Processor auszuführen. Das kann z. B. aus folgenden Gründen sinnvoll sein:

Beheben Sie zeitweilige Probleme mit bestimmten API-Anfragen, die auf ein Problem mit einer bestimmten Apigee-Komponente (Router/Message Processor) hinweisen.
Sie können weitere Diagnoseinformationen erfassen, indem Sie den Debug-Modus für eine bestimmte Instanz einer Apigee-Komponente aktivieren.
Schließen Sie aus, dass das Problem durch eine bestimmte Apigee-Komponente verursacht wird.
Prüfen Sie, ob Vorgänge wie das Erstellen einer neuen Instanz oder das Neustarten der Instanz die gewünschte Wirkung haben.

Vorbereitung

Direkter Zugriff auf die Router- oder Message Processor-Komponenten, für die API-Anfragen ausgeführt werden müssen.
Das cURL-Tool muss auf der jeweiligen Instanz der Komponente installiert sein.
Die API-Anfrage, die Sie im cURL-Format testen möchten.

Hier ist beispielsweise ein curl-Befehl, mit dem Sie von Ihrem lokalen Computer aus eine Anfrage an einen API-Proxy senden können:
```
curl https://myorg-test.mycompany.com/v1/customers -H 'Authorization: Bearer AxLqyU09GA10lrAiVRQCGXzMi9W2'
```
Hinweis :Probleme wie fehlende Bereitstellungen lassen sich auch mit einem teilweisen curl erkennen. Solange der Traffic an den richtigen Proxy gesendet wird, für den nur der richtige Host und der richtige Basispfad erforderlich sind, können Sie nützliche Tests durchführen, ohne Header zu haben, die für eine Erfolgsantwort erforderlich wären, z. B. einen Autorisierungsheader. In diesem Fall wäre das obige Beispiel ohne den Header ein gültiger Testlauf:
```
curl https://myorg-test.mycompany.com/v1/customers
```

API-Anfragen direkt an Apigee-Router senden

Szenario 1: API-Anfragen an Hostalias, die auf Router verweisen

Wenn der DNS-Eintrag des Host-Alias so konfiguriert ist, dass er auf die Apigee Edge-Router verweist (d. h. es gibt keinen Elastic Load Balancer (ELB)), können Sie die folgenden curl-Befehle verwenden, um die API-Anfragen direkt an einen Router zu senden:

Virtueller Host für nicht sichere Kommunikation über Port 80 konfiguriert

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

Beispiel:

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

Der virtuelle Host ist so konfiguriert, dass SSL auf Port 443 auf dem Router beendet wird.

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

Beispiel:

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

Szenario 2: API-Anfragen an Hostalias, die auf ELBs verweisen

Wenn der DNS-Eintrag des Host-Alias so konfiguriert ist, dass er auf einen Elastic Load Balancer (ELB) verweist, können Sie die folgenden curl-Befehle verwenden, um die API-Anfragen direkt an einen Router zu senden:

Virtueller Host für nicht sichere Kommunikation über Port 80 konfiguriert

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

Beispiel:

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

Für einen hohen Port konfigurierter virtueller Host und SSL wird auf einem Load-Balancer vor dem Apigee-Router beendet

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

Beispiel:

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

Virtueller Host für einen hohen Port konfiguriert und SSL wird auf dem Apigee-Router beendet

Der Load Balancer ist also so konfiguriert, dass er TCP-Passthrough zum Apigee-Router verwendet.

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

Beispiel:

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

Anfragen direkt an Apigee-Nachrichtenprozessoren senden

Szenario 1: API-Anfrage an den Message Processor über den Standardport 8998

Der Standardport, an dem der Message Processor auf Traffic vom Apigee-Router wartet, ist 8998. Daher muss der Traffic in allen Fällen, in denen dieser Port nicht geändert wurde, direkt an diesen Port auf einer bestimmten Message Processor-Instanz gesendet werden, wie im folgenden Beispiel. Die curl-Anfrage muss an die URL http://INTERNAL_IP_OF_MP:8998 gesendet werden. Außerdem muss der Header X-Apigee.Host mit dem Wert „hostname“ (einschließlich des in den virtuellen Hosts verwendeten Ports) gesendet werden, wie in den folgenden drei Beispielen gezeigt:

Der virtuelle Host ist für die SSL-Terminierung auf dem Router konfiguriert.

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

Beispiel:

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

Der virtuelle Host ist für einen „High Port“ konfiguriert und die SSL-Terminierung erfolgt auf einem Load Balancer ODER auf einem Apigee-Router:

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

Beispiel:

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

Der virtuelle Host ist für den Standard-HTTP-Port 80 konfiguriert.

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

Beispiel:

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

Szenario 2: API-Anfrage an Message Processor über SSL-Port 8443

Es ist möglich, die SSL-Kommunikation zwischen Router und Message Processor zu konfigurieren. In den folgenden Beispielen wird Port 8443 verwendet, der in der Apigee-Dokumentation empfohlen wird.

Der virtuelle Host ist für die SSL-Terminierung auf dem Router konfiguriert.

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

Beispiel:

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

Der virtuelle Host ist für die SSL-Terminierung auf einem Load Balancer konfiguriert und der Traffic wird an einen hohen Port des Routers weitergeleitet.
```
curl -v https://INTERNAL_IP_OF_MP:8443/PROXY_BASE_PATH/ -H 'HEADER: VALUE' -H 'X-Apigee.Host: HOST_ALIAS:PORT_NUMBER'
```
Beispiel:
```
curl -v https://10.10.53.115:8443/v1/customers -H 'Authorization: Bearer AxLqyU09GA10lrAiVRQCGXzMi9W2' -H 'X-Apigee.Host: myorg-test.mycompany.com:19001'
```
Hinweis :Derselbe curl-Befehl wird für Anfragen verwendet, die Mutual SSL verwenden. Diese Anfragen können daher nicht ohne Clientzertifikat getestet werden.