Informacje o trasach

Przeglądasz dokumentację Apigee Edge.
Otwórz dokumentację Apigee X.
Informacje

Trasa określa ścieżkę żądania z punktu ProxyEndpoint do docelowego punktu końcowego. Trasa obejmuje adres URL używany do uzyskiwania dostępu do punktu końcowego API ProxyEndpoint i adres URL usługi backendu zdefiniowanej przez docelowy punkt końcowy.

Obejrzyj film, w którym znajdziesz wprowadzenie do tras i opisanie relacji między punktem ProxyEndpoint a elementem TargetEndpoint.

Określam adres URL punktu końcowego serwera proxy interfejsu API

Poniższy obraz przedstawia żądanie przychodzące z aplikacji do ProxyEndpoint i kierowanie do usługi backendu:

Gdy utworzysz serwer proxy interfejsu 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 w 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 wdrożyć go w jednym lub w obu środowiskach.
  • Tworząc serwer proxy interfejsu API, zdefiniowane są parametry {base-path} i {resource-path}.

Gdy do Edge przychodzi żądanie, Edge analizuje adres URL, aby przekierować żądanie do odpowiedniego punktu ProxyEndpoint. Na przykład ten URL umożliwia dostęp do serwera proxy interfejsu API w Edge:

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

Jeśli sprawdzisz definicję ProxyEndpoint dla serwera proxy interfejsu API na ilustracji powyżej, możesz zobaczyć, jak ten URL jest analizowany przez Edge:

  1. Część adresu URL (http://myOrg-prod.apigee.net) odpowiada hostowi wirtualnemu w Edge. W powyższej definicji punktu końcowego ProxyEndpoint serwer proxy interfejsu API używa tagu <VirtualHost>, aby odnosić się do hosta wirtualnego o nazwie default. W środowisku możesz mieć zdefiniowanych wiele hostów wirtualnych.

    Host wirtualny definiuje domeny i porty, na których dostępny jest serwer proxy interfejsu API. Host wirtualny określa też, czy dostęp do serwera proxy interfejsu API jest możliwy przez protokół HTTP czy zaszyfrowany protokół HTTPS. Szczegółowe informacje o hostach wirtualnych znajdziesz w artykule Informacje o hostach wirtualnych (beta).
  2. Druga część adresu URL, /v1/pogoda, jest określana przez element <BasePath> w punkcie ProxyEndpoint. Ścieżka bazowa musi być unikalna dla serwera proxy interfejsu API w środowisku, aby dwa serwery proxy interfejsu API nie miały tej samej ścieżki bazowej.
  3. Trzecia część adresu URL, /forecastrss, to zasób zdefiniowany przez serwer proxy interfejsu API wraz z odpowiednim przepływem warunkowym zdefiniowanym w tagu <Flows>.

Film: obejrzyj krótki film, aby dowiedzieć się więcej o punktach końcowych serwera proxy interfejsu API.

Określanie adresu URL docelowego punktu końcowego

Tag <RouteRule> w definicji punktu końcowego ProxyEndpoint określa miejsce docelowe serwera proxy interfejsu API i jest oceniany po przetworzeniu wszystkich zasad w przepływach wstępnego, warunkowego i PostFlow żądania ProxyEndpoint.

ProxyEndpoint może zdefiniować miejsce docelowe jako:

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

Film: obejrzyj krótki film, aby dowiedzieć się więcej o docelowych punktach końcowych.

Bezpośredni URL

ProxyEndpoint może bezpośrednio wywoływać usługę backendu z pominięciem dowolnej nazwanej konfiguracji TargetEndpoint. Na przykład ten tag <RouteRule> zawsze wysyła wywołanie HTTP do strony http://api.mycompany.com/myAPI:

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

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

Pojedynczy cel

W definicji pojedynczej definicji celu obiekt ProxyEndpoint odwołuje się do pojedynczej definicji punktu końcowego docelowego według nazwy, tak jak to widać na ilustracji powyżej:

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

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

Cele warunkowe

Tag <RouteRule> pozwala skierować żądanie do elementu docelowego na podstawie określonego 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. W adresie URL żądania możesz np. uwzględnić obszar geograficzny, taki jak Stany Zjednoczone czy Wielka Brytania. Możesz wówczas przekierować żądanie do docelowego punktu końcowego opartego na regionie.

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 docelowego o nazwie TargetEndpoint1. Jeśli nie, żądanie jest przekierowywane 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 wiele reguł trasy, utwórz jedną jako „domyślną”, czyli regułę trasy bez warunku. Sprawdź, czy domyślna reguła trasy jest zdefiniowana jako ostatnia na liście tras warunkowych, ponieważ reguły są oceniane z góry w punkcie końcowym ProxyEndpoint.

Zobacz też trasy warunkowe i informacje o warunkach.

Film: obejrzyj krótki film, aby dowiedzieć się, jak kierować do docelowego punktu końcowego przy użyciu celów warunkowych.

Trasa null

Trasa o wartości null obsługuje scenariusze, w których komunikat żądania nie musi być przekazywany do docelowego punktu końcowego. Jest to przydatne, gdy ProxyEndpoint wykonuje wszystkie niezbędne przetwarzanie, na przykład używając JavaScriptu do wywołania usługi zewnętrznej.

Poniższy przykład zawiera definicję trasy o wartości null:

<RouteRule name="GoNowhere"/>

Więcej informacji