Антипаттерн: определение нескольких ProxyEndpoints в прокси-сервере API.

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

Конфигурация ProxyEndpoint определяет способ использования клиентскими приложениями API через Apigee Edge. ProxyEndpoint определяет URL-адрес прокси-сервера API и поведение прокси-сервера: какие политики применять и к каким целевым конечным точкам маршрутизироваться, а также условия, которые необходимо выполнить для выполнения этих политик или правил маршрутизации.

Короче говоря, конфигурация ProxyEndpoint определяет все, что необходимо сделать для реализации API.

Антипаттерн

Прокси-сервер API может иметь одну или несколько конечных точек прокси-сервера. Определение нескольких ProxyEndpoints — это простой и простой механизм реализации нескольких API в одном прокси. Это позволяет повторно использовать политики и/или бизнес-логику до и после вызова TargetEndpoint.

С другой стороны, при определении нескольких ProxyEndpoints в одном прокси API вы в конечном итоге концептуально объединяете множество несвязанных API в один артефакт. Это усложняет чтение, понимание, отладку и обслуживание прокси-серверов API. Это противоречит основной философии прокси API: упрощению создания и поддержки API для разработчиков.

Влияние

Несколько ProxyEndpoints в прокси API могут:

  • Усложните разработчикам понимание и поддержку прокси-сервера API.
  • Запутать аналитику. По умолчанию аналитические данные агрегируются на уровне прокси. Разбивка показателей по конечным точкам прокси отсутствует, если вы не создаете собственные отчеты.
  • Затрудните устранение проблем с прокси-серверами API.

Лучшая практика

При реализации нового прокси-сервера API или изменении существующего прокси-сервера API используйте следующие рекомендации:

  1. Реализуйте один прокси-сервер API с одной ProxyEndpoint.
  2. Если существует несколько API-интерфейсов, которые используют общий целевой сервер и/или требуют одной и той же логики до или после вызова целевого сервера, рассмотрите возможность использования общих потоков для реализации такой логики в разных прокси-серверах API.
  3. Если существует несколько API, которые имеют общий начальный базовый путь, но отличаются суффиксом, используйте условные потоки в одной ProxyEndpoint.
  4. Если существует прокси-сервер API с несколькими ProxyEndpoints и с ним нет проблем, предпринимать какие-либо действия не требуется.

Использование одной ProxyEndpoint для каждого прокси-сервера API приводит к:

  1. Более простые и легкие в обслуживании прокси
  2. Более качественная информация в аналитике, такая как производительность прокси-сервера и целевое время ответа, будет сообщаться отдельно, а не объединяться для всех ProxyEndpoints.
  3. Более быстрое устранение неполадок и решение проблем

Дальнейшее чтение

,

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

Конфигурация ProxyEndpoint определяет способ использования клиентскими приложениями API через Apigee Edge. ProxyEndpoint определяет URL-адрес прокси-сервера API и поведение прокси-сервера: какие политики применять и к каким целевым конечным точкам маршрутизироваться, а также условия, которые необходимо выполнить для выполнения этих политик или правил маршрутизации.

Короче говоря, конфигурация ProxyEndpoint определяет все, что необходимо сделать для реализации API.

Антипаттерн

Прокси-сервер API может иметь одну или несколько конечных точек прокси-сервера. Определение нескольких ProxyEndpoints — это простой и простой механизм реализации нескольких API в одном прокси. Это позволяет повторно использовать политики и/или бизнес-логику до и после вызова TargetEndpoint.

С другой стороны, при определении нескольких ProxyEndpoints в одном прокси API вы в конечном итоге концептуально объединяете множество несвязанных API в один артефакт. Это усложняет чтение, понимание, отладку и обслуживание прокси-серверов API. Это противоречит основной философии прокси API: упрощению создания и поддержки API для разработчиков.

Влияние

Несколько ProxyEndpoints в прокси API могут:

  • Усложните разработчикам понимание и поддержку прокси-сервера API.
  • Запутать аналитику. По умолчанию аналитические данные агрегируются на уровне прокси. Разбивка показателей по конечным точкам прокси отсутствует, если вы не создаете собственные отчеты.
  • Затрудните устранение проблем с прокси-серверами API.

Лучшая практика

При внедрении нового прокси-сервера API или изменении существующего прокси-сервера API используйте следующие рекомендации:

  1. Реализуйте один прокси-сервер API с одной ProxyEndpoint.
  2. Если существует несколько API-интерфейсов, которые используют общий целевой сервер и/или требуют одной и той же логики до или после вызова целевого сервера, рассмотрите возможность использования общих потоков для реализации такой логики в разных прокси-серверах API.
  3. Если существует несколько API, которые имеют общий начальный базовый путь, но отличаются суффиксом, используйте условные потоки в одной ProxyEndpoint.
  4. Если существует прокси-сервер API с несколькими ProxyEndpoints и с ним нет проблем, предпринимать какие-либо действия не требуется.

Использование одной ProxyEndpoint для каждого прокси-сервера API приводит к:

  1. Более простые и легкие в обслуживании прокси
  2. Более качественная информация в Analytics, такая как производительность прокси-сервера и целевое время ответа, будет сообщаться отдельно, а не объединяться для всех ProxyEndpoints.
  3. Более быстрое устранение неполадок и решение проблем

Дальнейшее чтение