Понимание маршрутов

Вы просматриваете документацию Apigee Edge .
Перейдите в документацию Apigee X.info

Маршрут определяет путь запроса от ProxyEndpoint к TargetEndpoint. В маршрут входят URL-адрес, используемый для доступа к API ProxyEndpoint, и URL-адрес бэкэнд-сервиса, определенного TargetEndpoint.

Определение URL-адреса конечной точки прокси-сервера API.

На следующем изображении показан запрос, поступающий в ProxyEndpoint из приложения, и этот запрос, перенаправляемый на серверную часть:

После создания API-прокси в Edge, URL-адрес по умолчанию, используемый приложением для доступа к прокси, имеет следующий вид:

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

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

где:

• {org-name} — это название вашей организации. Это имя создается при создании учетной записи в Edge.
• {env-name} — это имя среды Edge. По умолчанию все организации Apigee, созданные в облаке, имеют две среды: « test » и « prod ». При развертывании API-прокси вы можете выбрать развертывание в одной или обеих средах.
• {base-path} и ​​{resource-path} определяются при создании API-прокси.

Когда в Edge поступает запрос, Edge анализирует URL-адрес, чтобы направить запрос к правильному ProxyEndpoint. Например, для доступа к API-прокси в Edge используется следующий URL-адрес:

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

Если вы изучите определение ProxyEndpoint для API-прокси на рисунке выше, вы увидите, как Edge обрабатывает этот URL-адрес:

1. Домен в URL-адресе, http://myOrg-prod.apigee.net , соответствует виртуальному хосту в Edge. В приведенном выше определении ProxyEndpoint API-прокси использует тег <VirtualHost> для ссылки на виртуальный хост с именем default . В вашей среде может быть определено несколько виртуальных хостов.
   
   Виртуальный хост определяет домены и порты, через которые доступен API-прокси. Виртуальный хост также определяет, осуществляется ли доступ к API-прокси по протоколу HTTP или по зашифрованному протоколу HTTPS. Подробную информацию о виртуальных хостах см. в разделе «О виртуальных хостах (бета-версия)» .
2. Вторая часть URL, /v1/weather , определяется элементом <BasePath> в ProxyEndpoint. Базовый путь должен быть уникальным для прокси-сервера API в данной среде, чтобы два прокси-сервера API не имели одинаковый базовый путь.
3. Третья часть URL-адреса, /forecastrss , представляет собой ресурс, определенный API-прокси, с соответствующим условным потоком, заданным тегом <Flows> .

Определение URL-адреса целевой конечной точки

Тег <RouteRule> в определении ProxyEndpoint определяет цель API-прокси и оценивается после обработки всех политик в PreFlow, Conditional Flows и PostFlow запроса ProxyEndpoint.

В качестве целевого объекта в ProxyEndpoint можно указать следующее:

• Прямая ссылка на серверную часть.
• Единое определение TargetEndpoint.
• В нескольких целевых точках API-прокси делегирует запрос целевой конечной точке на основе заданного условия.
• Пустой маршрут или целевой объект означает, что запрос не перенаправляется на целевой объект. Вместо этого вся обработка запроса и генерация ответа происходит на Edge.

Прямая ссылка

ProxyEndpoint может напрямую вызывать бэкэнд-сервис, минуя любую конфигурацию именованного TargetEndpoint. Например, следующее правило маршрутизации (<RouteRule>) всегда выполняет HTTP-запрос к http://api.mycompany.com/myAPI:

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

Однако, поскольку отсутствует TargetEndpoint, вы можете добавлять политики только к потокам, определенным ProxyEndpoint.

Одна цель

В определении одной целевой точки ProxyEndpoint ссылается на определение одной целевой точки TargetEndpoint по имени, как показано на рисунке выше:

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

Все запросы к этому API-прокси направляются к одному и тому же определению TargetEndpoint. Тег <URL> в TargetEndpoint определяет местоположение бэкэнд-сервиса. На рисунке выше целевой URL — http://weather.yahooapis.com .

Условные цели

Тег <RouteRule> позволяет направлять запрос к целевому объекту на основе заданного условия. Для определения целевой конечной точки можно использовать переменные потока, параметры запроса, HTTP-заголовки, содержимое сообщения или контекстную информацию, такую ​​как время суток и локаль. Например, в URL-адрес запроса можно указать географический регион, например, США или Великобританию. Затем запрос можно направить к целевой конечной точке в зависимости от региона.

Следующее правило маршрутизации оценивает HTTP-заголовок в запросе. Если HTTP-заголовок routeTo имеет значение TargetEndpoint1 , то запрос перенаправляется на целевой объект TargetEndpoint1. В противном случае запрос перенаправляется на целевой объект TargetEndpoint2.

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

Если у вас несколько правил маршрутизации, создайте одно из них в качестве «по умолчанию», то есть правило маршрутизации без условий. Убедитесь, что правило маршрутизации по умолчанию определено последним в списке условных маршрутов, поскольку правила оцениваются сверху вниз в ProxyEndpoint.

См. также разделы«Условные маршруты» и «Справочник по условиям» .

Пустой маршрут

Нулевой маршрут поддерживает сценарии, в которых сообщение запроса не нужно перенаправлять в TargetEndpoint. Это полезно, когда ProxyEndpoint выполняет всю необходимую обработку, например, используя JavaScript для вызова внешнего сервиса.

В следующем примере определяется нулевой маршрут:

<RouteRule name="GoNowhere"/>

Узнать больше

• О виртуальных хостах
• Справочник по настройке API-прокси
• Справочник свойств конечной точки
• Балансировка нагрузки между серверными бэкэндами