Informationen zu Routen

Sie sehen sich die Dokumentation zu Apigee Edge an.
Sehen Sie sich die Apigee X-Dokumentation an.
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 ProxyEndpoint und TargetEndpoint.

Die URL des API-Proxy-Endpunkts bestimmen.

Die folgende Abbildung zeigt eine Anfrage, die von einer Anwendung an den ProxyEndpoint kommt und an den Back-End-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. Sie können einen API-Proxy in einer oder in 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 Abbildung oben überprüfen, sehen Sie, 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 verwendet der API-Proxy das Tag <VirtualHost>, um auf einen virtuellen Host mit dem Namen default zu verweisen. Sie können in Ihrer Umgebung mehrere virtuelle Hosts definieren.

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

Video: Schauen Sie sich ein kurzes Video an, um mehr über die API-Proxy-Endpunkte zu erfahren.

URL des Zielendpunkts ermitteln

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

Ein ProxyEndpoint kann das Ziel so definieren:

  • Eine direkte URL zu einem Back-End-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 erfolgt die gesamte Verarbeitung der Anfrage und die Generierung der Antwort in Edge.

Video: In diesem kurzen Video erfahren Sie mehr über Zielendpunkte.

Direkte URL

Ein ProxyEndpoint kann einen Back-End-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 vom 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 Tag <URL> im TargetEndpoint legt den Standort des Back-End-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, Abfrageparameter, 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 namens TargetEndpoint1 weitergeleitet. Ist dies nicht der Fall, 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. als Routingregel 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.

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

Nullroute

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