<ph type="x-smartling-placeholder"></ph>
Sie sehen die Dokumentation zu Apigee Edge.
Gehen Sie zur
Apigee X-Dokumentation. Weitere Informationen
Eine Route bestimmt den Pfad einer Anfrage vom ProxyEndpoint zum TargetEndpoint. In der Route sind die URL enthalten, die für den Zugriff auf den API-ProxyEndpoint und die URL des Back-Ends verwendet werden. des vom TargetEndpoint definierten Diensts.
In diesem Video erhalten Sie eine Einführung in Routen, in der die Beziehung zwischen den ProxyEndpoint und der TargetEndpoint.
Die URL des API-Proxy-Endpunkts bestimmen.
Die folgende Abbildung zeigt eine Anfrage, die von einer Anwendung beim ProxyEndpoint eingeht, und dass Anfrage, die an den Back-End-Dienst weitergeleitet wird:
Nachdem Sie einen API-Proxy in Edge erstellt haben, ist die Standard-URL, mit der eine Anwendung auf den Proxy zugreift, hat folgendes 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 den Namen 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. Wenn Sie einen API-Proxy bereitstellen, können Sie ihn in einer oder in beiden Umgebungen bereitstellen.
- {base-path} und {base-path} werden definiert, wenn erstellen Sie den API-Proxy.
Wenn eine Anfrage bei Edge eingeht, parst Edge die URL, um die Anfrage an die richtige ProxyEndpoint. Die folgende URL wird beispielsweise 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 untersuchen, werden Sie feststellen, wie diese URL von Edge geparst wird:
- Der Domainteil der URL, http://myOrg-prod.apigee.net entspricht
zu einem virtuellen Host in Edge. In der obigen ProxyEndpoint-Definition muss der API-Proxy
das Tag <VirtualHost> für Folgendes verwendet:
auf einen virtuellen Host namens default verweisen Sie können mehrere virtuelle
der in Ihrer Umgebung definierten Hosts.
Ein virtueller Host definiert die Domains und Ports, auf denen ein API-Proxy verfügbar gemacht wird. Ein virtueller Host definiert außerdem, ob der Zugriff auf den API-Proxy über das HTTP-Protokoll oder die verschlüsselte HTTPS-Protokoll. Weitere Informationen zu virtuellen Hosts finden Sie unter Informationen zu virtuellen Hosts (Beta). - Der zweite Teil der URL, /v1/weather, wird durch das Attribut <BasePath>-Element im ProxyEndpoint. Der Basispfad muss für den API-Proxy für die Umgebung eindeutig sein, sodass zwei API-Proxys haben nicht den gleichen Basispfad.
- Der dritte Teil der URL, /forecastrss ist eine Ressource, die vom API-Proxy mit dem entsprechenden bedingten Ablauf, der durch das <Flows>-Tag 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 einem Die ProxyEndpoint-Definition bestimmt das Ziel des API-Proxys und wird schließlich ausgewertet Richtlinien in PreFlow, Conditional Flows und PostFlow der ProxyEndpoint-Anfrage verarbeitet werden.
Ein ProxyEndpoint kann das Ziel so definieren:
- Eine direkte URL zu einem Back-End-Dienst.
- Eine einzelne TargetEndpoint-Definition.
- Mehrere TargetEndpunkte, bei denen der API-Proxy die Anfrage an ein Ziel delegiert Endpunkt basierend auf einer Bedingung.
- Nullroute oder kein Ziel, d. h., die Anfrage wird nicht an ein Ziel weitergeleitet. Stattdessen werden alle Die Verarbeitung der Anfrage und die Generierung der Antwort erfolgt in Edge.
Video: In diesem kurzen Video erfahren Sie mehr über Zielendpunkte.
Direkte URL
Ein ProxyEndpoint kann einen Back-End-Dienst direkt aufrufen und so jeden benannten TargetEndpoint umgehen. Konfiguration. Beispielsweise erstellt die folgende <RouteRule> immer eine HTTP- Aufruf von http://api.mycompany.com/myAPI::
<RouteRule name="default"> <URL>http://api.mycompany.com/myAPI</URL> </RouteRule>
Da jedoch kein TargetEndpoint vorhanden ist, können Sie Richtlinien nur den definierten Abläufen hinzufügen. durch den ProxyEndpoint.
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. Die <URL>-Tag im TargetEndpoint bestimmt den Standort des Back-End-Dienstes. In der Abbildung oben wird das Ziel Die URL lautet http://weather.yahooapis.com.
Bedingte Ziele
Mit dem Tag <RouteRule> können wird eine Anfrage basierend auf einer Bedingung an ein Ziel weitergeleitet. 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 hat den Wert TargetEndpoint1, dann wird die Anfrage wird an den TargetEndpoint namens TargetEndpoint1 weitergeleitet. Andernfalls wird die Anfrage weitergeleitet. an TargetEndpoint2.
<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 Route für eine Regel ohne Bedingung. Achten Sie darauf, dass die Standardroutingregel an letzter Stelle in der Liste definiert ist von bedingten Routen, da Regeln von oben im ProxyEndpoint 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 Null-Route unterstützt Szenarien, in denen die Anfragenachricht nicht weitergeleitet werden muss an einen TargetEndpoint. Dies ist nützlich, wenn ProxyEndpoint die erforderliche Verarbeitung ausführt, indem Sie z. B. mit JavaScript einen externen Dienst aufrufen.
Im folgenden Beispiel wird eine Nullroute definiert:
<RouteRule name="GoNowhere"/>