Informacje o trasach

Przeglądasz dokumentację Apigee Edge.
Przejdź do Dokumentacja Apigee X. informacje.

Trasa określa ścieżkę żądania od punktu ProxyEndpoint do docelowego punktu końcowego. Trasa zawiera adres URL służący do uzyskiwania dostępu do punktu końcowego serwera proxy interfejsu API oraz adres URL backendu. zdefiniowaną przez docelowy punkt końcowy.

Określanie adresu URL serwera proxy interfejsu API punkt końcowy

Poniższa ilustracja przedstawia żądanie przychodzące do punktu końcowego serwera proxy z aplikacji oraz żądania kierowane do usługi backendu:

Gdy utworzysz serwer proxy interfejsu API na Edge, domyślny adres URL używany przez aplikację 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:

• Organizacja {org-name} to nazwę organizacji. Ta nazwa jest tworzona podczas tworzenia konta na Edge.
• {env-name} to Nazwa środowiska brzegowego. Domyślnie wszystkie organizacje Apigee utworzone w chmurze udostępnione w dwóch środowiskach: „test” i „prod”. Podczas wdrażania serwera proxy interfejsu API możesz ją wdrożyć w jednym lub obu środowiskach.
• Ścieżki {base-path} i {base-path} są zdefiniowane, gdy utworzysz serwer proxy interfejsu API.

Gdy żądanie dociera do Edge, Edge analizuje adres URL, aby skierować je na prawidłowy adres. 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 sprawdzisz definicję punktu końcowego serwera proxy interfejsu API na ilustracji powyżej, możesz zobaczyć, jak Edge analizuje ten adres URL:

1. Część adresu URL związana z domeną (http://myOrg-prod.apigee.net) odpowiada z hostem wirtualnym na Edge. W powyższej definicji ProxyEndpoint serwer proxy interfejsu API używa tagu <VirtualHost> do odwołuje się do hosta wirtualnego o nazwie default. Możesz mieć wiele hostów zdefiniowanych w Twoim środowisku.
   
   Host wirtualny definiuje domeny i porty, w których jest dostępny serwer proxy interfejsu API. Host wirtualny określa też, czy dostęp do serwera proxy interfejsu API jest możliwy za pomocą protokołu HTTP czy za pomocą 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 na podstawie <BasePath> w tagu ProxyEndpoint. Ścieżka podstawowa musi być unikalna dla serwera proxy interfejsu API w środowisku, tak aby dwa Serwery proxy interfejsu API nie mają takiej samej ścieżki podstawowej.
3. Trzecia część adresu URL (/forecastrss) to zasób zdefiniowany przez klucz Serwer proxy interfejsu API z odpowiednim przepływem warunkowym zdefiniowanym przez tag <Flows>.

Określanie adresu URL docelowego punktu końcowego

Tag <RouteRule> w tagu Definicja punktu końcowego serwera proxy określa miejsce docelowe serwera proxy interfejsu API i jest oceniana po zasady PreFlow, przepływów warunkowych i PostFlow żądania ProxyEndpoint są przetworzono.

Punkt końcowy serwera proxy może zdefiniować środowisko docelowe jako:

• Bezpośredni URL do usługi backendu.
• Pojedyncza definicja docelowego punktu końcowego.
• Wiele punktów TargetEndpoints, w przypadku których serwer proxy interfejsu API deleguje żądanie do środowiska docelowego na podstawie warunku.
• Trasa lub cel o wartości null – żądanie nie zostało przekazane do celu. Zamiast tego wszystkie funkcje przetwarzania żądania i generowania odpowiedzi odbywa się na Edge.

Bezpośredni URL

Punkt ProxyEndpoint może bezpośrednio wywołać usługę backendu z pominięciem nazwanego punktu docelowego konfiguracji. Na przykład ta <RouteRule> zawsze powoduje wywołanie pod adresem http://api.mycompany.com/myAPI:

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

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

Pojedynczy cel

W pojedynczej definicji docelowej punkt końcowy ProxyEndpoint odwołuje się do pojedynczej definicji docelowego punktu końcowego według nazwy, tak jak 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 punktu końcowego. <URL> w sekcji Docelowy punkt końcowy określa lokalizację usługi backendu. na powyższej ilustracji wartość docelowa URL to http://weather.yahooapis.com.

Cele warunkowe

Tag <RouteRule> pozwala kierowanie żądania do celu na podstawie warunku. Możesz używać zmiennych przepływu, zapytań parametry, nagłówki HTTP, treść wiadomości lub informacje kontekstowe, takie jak pora dnia i język aby określić docelowy punkt końcowy. Możesz na przykład uwzględnić obszar geograficzny, taki jak Stany Zjednoczone i Wielkiej Brytanii w adresie URL żądania. Następnie możesz kierować żądanie do docelowego punktu końcowego na podstawie i regionie.

Poniższa reguła trasy ocenia nagłówek HTTP w żądaniu. Jeśli nagłówek HTTP routeTo ma wartość TargetEndpoint1, a potem żądanie jest przekierowywany do docelowego punktu końcowego o nazwie TargetEndpoint1. Jeśli nie, prośba zostanie przekazana dalej. do docelowego punktu końcowego2.

<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ą z nich jako domyślną, czyli trasę, bez warunku. 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 serwera proxy.

Zobacz też Trasy warunkowe i Informacje o warunkach.

Trasa null

Trasa o wartości null obsługuje scenariusze, w których nie trzeba przekazywać wiadomości żądania docelowy punkt końcowy. Jest to przydatne, gdy punkt końcowy proxy wykonuje wszystkie niezbędne przetwarzanie, np. używając JavaScriptu do wywoływania usług zewnętrznych.

Ten przykład definiuje trasę o wartości null:

<RouteRule name="GoNowhere"/>

Więcej informacji

• Informacje o hostach wirtualnych
• Dokumentacja konfiguracji serwera proxy interfejsu API
• Informacje o właściwościach punktu końcowego
• Równoważenie obciążenia między serwerami backendu