Informationen zu Routen

Sie lesen gerade die Dokumentation zu Apigee Edge.
Zur Dokumentation vonApigee X.
info

Eine Route bestimmt den Pfad einer Anfrage vom ProxyEndpoint zum TargetEndpoint. In dieser Route ist die URL enthalten, die für den Zugriff auf den API-ProxyEndpoint verwendet wird, und die URL des Back-End Dienstes, der durch den TargetEndpoint definiert wird.

In diesem Video erhalten Sie eine Einführung in Routen mit einer Beschreibung der Beziehung zwischen dem ProxyEndpoint und dem TargetEndpoint.

Die URL des API-Proxy Endpunkts bestimmen

Die folgende Abbildung zeigt eine Anfrage, die von einer Anwendung an den ProxyEndpoint kommt und die Anfrage an den Backend-Dienst weitergeleitet wird:

Nachdem Sie einen API-Proxy in Edge erstellt haben, verwendet die Standard-URL, die eine Anwendung für den Zugriff auf den Proxy verwendet, das folgende Format:

http://{org-name}-{env-name}.apigee.net/{base-path}/{resource-path}

https://{org-name}-{env-name}.apigee.net/{base-path}/{resource-path}

Dabei gilt:

  • {org-name} ist der Name Ihrer Organisation. Dieser Name wird erstellt, wenn Sie ein Konto in Edge erstellen.
  • {env-name} ist der Name der Edge-Umgebung. Standardmäßig werden alle in der Cloud erstellten Apigee-Organisationen mit zwei Umgebungen bereitgestellt: „test“ und „prod“. Beim Bereitstellen eines API-Proxys, können Sie ihn in einer oder beiden Umgebungen bereitstellen.
  • {base-path} und {resource-path} werden beim Erstellen des API-Proxys definiert.

Wenn eine Anfrage bei Edge eingeht, parst Edge die URL, um die Anfrage an den richtigen ProxyEndpoint weiterzuleiten. Zum Beispiel wird die folgende URL für den Zugriff auf einen API-Proxy in Edge verwendet:

http://myOrg-prod.apigee.net/v1/weather/forecastrss

Wenn Sie die ProxyEndpoint-Definition für den API-Proxy in der obigen Abbildung überprüfen, können Sie sehen , wie diese URL von Edge geparst wird:

  1. Der Domainteil der URL, http://myOrg-prod.apigee.net, entspricht einem virtuellen Host in Edge. In der obigen ProxyEndpoint-Definition verweist der API-Proxy mit dem Tag <VirtualHost> auf einen virtuellen Host namens default. In Ihrer Umgebung können mehrere virtuelle Hosts definiert sein.

    Ein virtueller Host definiert die Domains und Ports, über die ein API-Proxy verfügbar gemacht wird. Ein virtueller Host definiert auch, ob auf den API-Proxy über das HTTP-Protokoll oder über das verschlüsselte HTTPS-Protokoll zugegriffen wird. Ausführliche Informationen zu virtuellen Hosts finden Sie unter Informationen zu virtuellen Hosts (Beta).
  2. Der zweite Teil der URL, /v1/weather, wird durch das <BasePath> Element im ProxyEndpoint bestimmt. Der Basispfad muss für den API-Proxy eindeutig sein, damit zwei API-Proxys nicht denselben Basispfad haben.
  3. Der dritte Teil der URL, /forecastrss, ist eine Ressource, die vom API-Proxy definiert wird und den entsprechenden bedingten Ablauf enthält, der durch das Tag <Flows> definiert wird.

Video:Sehen Sie sich ein Kurzvideo an, um mehr über API-Proxy-Endpunkte zu erfahren.

URL des Zielendpunkts ermitteln

Das Tag <RouteRule> in einer ProxyEndpoint-Definition bestimmt das Ziel des API-Proxys und wird nach der Auswertung aller Richtlinien in den PreFlow-, Conditional Flows und PostFlow der ProxyEndpoint-Anfrage verarbeitet.

Ein ProxyEndpoint kann das Ziel so definieren:

  • Eine direkte URL zu einem Backend-Dienst.
  • Eine einzelne TargetEndpoint-Definition.
  • Mehrere TargetEndpoints, bei denen der API-Proxy die Anfrage anhand einer Bedingung an einen Zielendpunkt delegiert.
  • Nullroute oder kein Ziel, d. h., die Anfrage wird nicht an ein Ziel weitergeleitet. Stattdessen findet die gesamte Verarbeitung der Anfrage und die Generierung der Antwort in Edge statt.

Video: Sehen Sie sich ein Kurzvideo an, um mehr über Zielendpunkte zu erfahren.

Direkte URL

Ein ProxyEndpoint kann einen Backend-Dienst direkt aufrufen und jede benannte TargetEndpoint Konfiguration umgehen. Die folgende <RouteRule> führt beispielsweise immer einen HTTP Aufruf an http://api.mycompany.com/myAPI: aus:

<RouteRule name="default">
  <URL>http://api.mycompany.com/myAPI</URL> 
</RouteRule>

Da es jedoch keinen TargetEndpoint gibt, können Sie Richtlinien nur zu den in ProxyEndpoint definierten Abläufen hinzufügen.

Einzelnes Ziel

In einer einzelnen Zieldefinition verweist der ProxyEndpoint auf eine einzelne TargetEndpoint-Definition , wie in der Abbildung oben dargestellt:

<RouteRule name="default">
  <TargetEndpoint>default</TargetEndpoint>
</RouteRule>

Alle Anfragen an diesen API-Proxy werden an dieselbe TargetEndpoint-Definition weitergeleitet. Das <URL> Tag im TargetEndpoint legt den Standort des Backend-Dienstes fest. In der Abbildung oben lautet die Ziel URL http://weather.yahooapis.com.

Bedingte Ziele

Mit dem Tag <RouteRule> können Sie eine Anfrage basierend auf einer Bedingung an ein Ziel weiterleiten. Sie können Ablaufvariablen, Abfrage parameter, HTTP-Header, Nachrichteninhalt oder Kontextinformationen wie Tageszeit und Sprache verwenden, um den Zielendpunkt zu ermitteln. Zum Beispiel können Sie einen geografischen Bereich, z. B. "US" und "UK", in eine Anfrage-URL aufnehmen. Anschließend können Sie eine Anfrage basierend auf der Region an einen Zielendpunkt weiterleiten.

Mit der folgenden Routingregel wird ein HTTP-Header in einer Anfrage ausgewertet. Wenn der HTTP-Header routeTo den Wert TargetEndpoint1 hat, wird die Anfrage an den TargetEndpoint mit dem Namen „TargetEndpoint1“ weitergeleitet. Andernfalls wird die Anfrage an „TargetEndpoint2“ weitergeleitet.

<RouteRule name="MyRoute">
  <Condition>request.header.routeTo = "TargetEndpoint1"</Condition>
  <TargetEndpoint>TargetEndpoint1</TargetEndpoint>
</RouteRule>
<RouteRule name="default">
 <TargetEndpoint>TargetEndpoint2</TargetEndpoint>
</RouteRule>

Wenn Sie mehrere Routingregeln haben, erstellen Sie eine als Standard, d. h. eine Routing regel ohne Bedingung. Achten Sie darauf, dass die Standard-Routingregel als letzte in der Liste der bedingten Routen definiert ist, da die Regeln im ProxyEndpoint von oben nach unten ausgewertet werden.

Siehe auch Bedingte Routen und Referenz für Bedingungen.

Kurzvideo:In diesem Kurzvideo erfahren Sie, wie Sie mithilfe von bedingten Zielen eine Weiterleitung an einen Zielendpunkt vornehmen.

Null route

Eine Nullroute unterstützt Szenarien, bei denen die Anfragenachricht nicht an einen TargetEndpoint weitergeleitet werden muss. Dies ist nützlich, wenn der ProxyEndpoint die gesamte erforderliche Verarbeitung ausführt, beispielsweise JavaScript zum Aufrufen eines externen Dienstes verwendet.

Im folgenden Beispiel wird eine Nullroute definiert:

<RouteRule name="GoNowhere"/>

Weitere Informationen