Informacje o trasach

Wyświetlasz dokumentację Apigee Edge.
Przejdź do dokumentacji Apigee X. info

Trasa określa ścieżkę żądania od ProxyEndpoint do TargetEndpoint. Obejmuje ona adres URL używany do uzyskiwania dostępu do ProxyEndpoint interfejsu API oraz adres URL usługi backendu zdefiniowanej przez TargetEndpoint.

Określanie adresu URL punktu końcowego proxy interfejsu API

Na ilustracji poniżej widać żądanie przychodzące do ProxyEndpoint z aplikacji i to żądanie kierowane do usługi backendu:

Po utworzeniu proxy interfejsu API w Edge domyślny adres URL, którego aplikacja używa do uzyskiwania dostępu do proxy ma postać:

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

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

gdzie:

• {org-name} to nazwa Twojej organizacji. Ta nazwa jest tworzona podczas tworzenia konta w Edge.
• {env-name} to nazwa środowiska Edge. Domyślnie wszystkie organizacje Apigee utworzone w chmurze są wyposażone w 2 środowiska: „test” i „prod”. Podczas wdrażania proxy interfejsu API, możesz wdrożyć je w jednym lub obu środowiskach.
• {base-path} i {resource-path} są definiowane podczas tworzenia proxy interfejsu API.

Gdy żądanie dociera do Edge, Edge analizuje adres URL, aby skierować żądanie do właściwego ProxyEndpoint. Na przykład ten adres URL służy do uzyskiwania dostępu do proxy interfejsu API w Edge:

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

Jeśli sprawdzisz definicję ProxyEndpoint dla proxy interfejsu API na ilustracji powyżej, zobaczysz jak ten adres URL jest analizowany przez Edge:

1. Część adresu URL, http://myOrg-prod.apigee.net, odpowiada hostowi wirtualnemu w Edge. W definicji ProxyEndpoint powyżej proxy interfejsu API używa tagu <VirtualHost> do odwoływania się do hosta wirtualnego o nazwie default. W środowisku możesz mieć zdefiniowanych wiele hostów wirtualnych.
   
   Host wirtualny określa domeny i porty, na których jest udostępniane proxy interfejsu API. Host wirtualny określa też, czy dostęp do proxy interfejsu API jest uzyskiwany za pomocą protokołu HTTP czy szyfrowanego protokołu HTTPS. Szczegółowe informacje o hostach wirtualnych znajdziesz w artykule Informacje o hostach wirtualnych (wersja beta).
2. Druga część adresu URL, /v1/weather, jest określana przez element <BasePath> w ProxyEndpoint. Ścieżka podstawowa musi być unikalna dla proxy interfejsu API w danym środowisku, aby 2 proxy interfejsu API nie miały tej samej ścieżki podstawowej.
3. Trzecia część adresu URL, /forecastrss, to zasób zdefiniowany przez proxy interfejsu API z odpowiednim przepływem warunkowym zdefiniowanym przez tag <Flows>.

Określanie adresu URL punktu końcowego docelowego

Tag <RouteRule> w definicji ProxyEndpoint określa cel proxy interfejsu API i jest oceniany po przetworzeniu wszystkich zasad w PreFlow, przepływach warunkowych i PostFlow żądania ProxyEndpoint.

ProxyEndpoint może zdefiniować cel jako:

• bezpośredni adres URL usługi backendu;
• pojedynczą definicję TargetEndpoint;
• wiele TargetEndpoints, w których proxy interfejsu API przekazuje żądanie do punktu końcowego docelowego na podstawie warunku;
• trasę lub cel zerowy, co oznacza, że żądanie nie jest przekazywane do celu. Zamiast tego całe przetwarzanie żądania i generowanie odpowiedzi odbywa się w Edge.

Bezpośredni adres URL

ProxyEndpoint może bezpośrednio wywoływać usługę backendu, pomijając dowolną nazwaną konfigurację TargetEndpoint. Na przykład ten tag <RouteRule> zawsze wykonuje wywołanie HTTP do http://api.mycompany.com/myAPI:

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

Ponieważ nie ma jednak TargetEndpoint, możesz dodawać zasady tylko do przepływów zdefiniowanych przez ProxyEndpoint.

Pojedynczy cel

W definicji pojedynczego celu ProxyEndpoint odwołuje się do pojedynczej definicji TargetEndpoint według nazwy, jak pokazano na ilustracji powyżej:

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

Wszystkie żądania wysyłane do tego proxy interfejsu API są kierowane do tej samej definicji TargetEndpoint. Tag <URL> w TargetEndpoint określa lokalizację usługi backendu. Na ilustracji powyżej docelowy adres URL to http://weather.yahooapis.com.

Cele warunkowe

Tag <RouteRule> umożliwia kierowanie żądania do celu na podstawie warunku. Do określania punktu końcowego docelowego możesz używać zmiennych przepływu, parametrów zapytania , nagłówków HTTP, treści wiadomości lub informacji kontekstowych, takich jak pora dnia i ustawienia regionalne ,. Możesz na przykład uwzględnić w adresie URL żądania obszar geograficzny, np. Stany Zjednoczone i Wielką Brytanię. Następnie możesz kierować żądanie do punktu końcowego docelowego na podstawie regionu.

Ta reguła trasy ocenia nagłówek HTTP w żądaniu. Jeśli nagłówek HTTP routeTo ma wartość TargetEndpoint1, żądanie jest przekazywane do TargetEndpoint o nazwie TargetEndpoint1. W przeciwnym razie żądanie jest przekazywane do TargetEndpoint2.

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

Jeśli masz kilka reguł trasy, utwórz jedną jako „domyślną”, czyli jako regułę trasy bez warunku. Upewnij się, że domyślna reguła trasy jest zdefiniowana jako ostatnia na liście tras warunkowych, ponieważ reguły są oceniane od góry do dołu w ProxyEndpoint.

Zobacz też Trasy warunkowe i Dokumentacja warunków.

Trasa zerowa

Trasa zerowa obsługuje sytuacje, w których wiadomość z żądaniem nie musi być przekazywana do TargetEndpoint. Jest to przydatne, gdy ProxyEndpoint wykonuje wszystkie niezbędne przetwarzanie, np. za pomocą JavaScriptu do wywoływania usługi zewnętrznej.

Ten przykład definiuje trasę zerową:

<RouteRule name="GoNowhere"/>

Więcej informacji

• Informacje o hostach wirtualnych
• Dokumentacja konfiguracji proxy interfejsu API
• Dokumentacja właściwości punktu końcowego
• Równoważenie obciążenia na serwerach backendu