Informacje o trasach

Wyświetlasz dokumentację Apigee Edge.
Zapoznaj się z dokumentacją Apigee X. Informacje

Trasa określa ścieżkę żądania od punktu ProxyEndpoint do docelowego punktu końcowego. Trasa obejmuje adres URL używany do uzyskania dostępu do punktu końcowego serwera proxy interfejsu API oraz adres URL usługi backendu zdefiniowanej przez element TargetEndpoint.

Ustalanie adresu URL punktu końcowego proxy interfejsu API

Na tym obrazie widać żądanie wysyłane do ProxyEndpoint z aplikacji i kierowanie tego żądania do usługi backendu:

Po utworzeniu serwera proxy API w Edge domyślny adres URL, którego aplikacja używa do uzyskiwania dostępu do serwera 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 na Edge.
• {env-name} to nazwa środowiska Edge. Domyślnie wszystkie organizacje Apigee utworzone w chmurze mają 2 środowiska: „test” i „prod”. Podczas wdrażania serwera proxy interfejsu API możesz wybrać, czy ma on być używany w jednym czy w obu środowiskach.
• Wartości {ścieżka-podstawowa} i {ścieżka-zasobu} są definiowane podczas tworzenia serwera proxy interfejsu API.

Gdy Edge otrzyma żądanie, przeanalizuje adres URL, aby przekierować je do odpowiedniego ProxyEndpoint. Na przykład ten adres URL służy do uzyskiwania dostępu do serwera proxy interfejsu API w Edge:

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

Jeśli spojrzysz na definicję punktu końcowego serwera proxy interfejsu API na ilustracji powyżej, zobaczysz, jak ten adres URL jest analizowany przez Edge:

1. Część domeny adresu URL http://myOrg-prod.apigee.net odpowiada wirtualnemu hostowi w Edge. W definicji ProxyEndpoint powyżej serwer proxy API używa tagu <VirtualHost> do odwołania się do hosta wirtualnego o nazwie default. W środowisku możesz zdefiniować wiele hostów wirtualnych.
   
   Host wirtualny definiuje domeny i porty, w których jest dostępny serwer proxy interfejsów API. Host wirtualny określa też, czy dostęp do serwera proxy 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 (beta).
2. Druga część adresu URL (/v1/Weather) jest określana przez element <BasePath> w ProxyEndpoint. Ścieżka podstawowa musi być unikalna dla każdego serwera proxy interfejsu API w danym środowisku, aby 2 serwery proxy interfejsu API nie miały tej samej ścieżki podstawowej.
3. Trzecia część adresu URL, /forecastrss, to zasób zdefiniowany przez serwer proxy interfejsu API z odpowiednim przepływem warunkowym zdefiniowanym za pomocą tagu <Flows>.

Określanie adresu URL docelowego punktu końcowego

Tag <RouteRule> w definicji ProxyEndpoint określa docelowy serwer proxy interfejsu API i jest oceniany po przetworzeniu wszystkich zasad w PreFlow, ConditionalFlow i PostFlow żądania ProxyEndpoint.

ProxyEndpoint może zdefiniować wartość docelową jako:

• Bezpośredni URL do usługi backendu.
• Pojedyncza definicja punktu końcowego docelowego.
• Wiele punktów końcowych docelowych, do których serwer proxy interfejsu API deleguje żądanie na podstawie warunku.
• Brak trasy lub celu, co oznacza, że żądanie nie jest przekazywane do celu. Zamiast tego wszystkie przetwarzanie żądania i generowanie odpowiedzi odbywa się w Edge.

Adres URL bezpośredni

Punkt końcowy pośredniczący może bezpośrednio wywołać usługę backendu, pomijając dowolną nazwaną konfigurację punktu końcowego docelowego. Na przykład ta reguła <RouteRule> zawsze wykonuje wywołanie HTTP do adresu http://api.mojadomena.com/mojeAPI:

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

Ponieważ nie ma punktu końcowego docelowego, możesz dodawać zasady tylko do przepływów zdefiniowanych przez punkt końcowy serwera proxy.

Pojedynczy cel

W definicji pojedynczego punktu docelowego element ProxyEndpoint odwołuje się do pojedynczej definicji elementu TargetEndpoint według nazwy, jak pokazano na rysunku powyżej:

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

Wszystkie żądania wysyłane do tego serwera proxy API są kierowane do tej samej definicji punktu końcowego docelowego. Tag <URL> w sekcji TargetEndpoint określa lokalizację usługi backendu. Na powyższym rysunku docelowy adres URL to http://weather.yahooapis.com.

Cele warunkowe

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

Poniższa reguła trasy ocenia nagłówek HTTP w żądaniu. Jeśli nagłówek HTTP routeTo ma wartość TargetEndpoint1, żądanie jest przekierowywane do punktu końcowego TargetEndpoint o nazwie TargetEndpoint1. Jeśli nie, żądanie jest przekierowywane do punktu końcowego docelowego 2.

<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 warunków. Sprawdź, czy domyślna reguła trasy jest zdefiniowana jako ostatnia na liście tras warunkowych, ponieważ reguły są oceniane od góry w punkcie końcowym w punkcie końcowym.

Zobacz też Kierunki warunkowe i Warunki.

Trasa null

Trasa o wartości null obsługuje scenariusze, w których wiadomość żądania nie musi być przekazywana do docelowego punktu końcowego. Jest to przydatne, gdy punkt końcowy proxy wykonuje wszystkie niezbędne przetwarzanie, np. używając JavaScriptu do wywoływania usługi zewnętrznej.

W tym przykładzie zdefiniowano trasę null:

<RouteRule name="GoNowhere"/>

Więcej informacji

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