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

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

Маршрут определяет путь запроса от 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. Например, следующий URL-адрес используется для доступа к прокси-серверу API в Edge:

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, условных потоках и PostFlow запроса ProxyEndpoint.

ProxyEndpoint может определить цель как:

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

Прямой URL-адрес

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 , то запрос перенаправляется в TargetEndpoint с именем 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
• Справочник по свойствам конечной точки
• Балансировка нагрузки между внутренними серверами