Что такое маршруты

Вы просматриваете документацию по 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, чтобы направить запрос в нужную конечную точку прокси. Например, следующий URL используется для доступа к прокси-серверу API в Edge:

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

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

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 можно указать целевой объект следующим образом:

• Прямой URL бэкенд-службы.
• Одно определение TargetEndpoint.
• Несколько TargetEndpoint, в которых прокси-сервер 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, запрос пересылается в конечную точку 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
• Справочник по свойствам конечных точек
• Балансировка нагрузки между внутренними серверами