Антишаблон: используйте политику вызова службы для вызова внутренней службы в прокси-сервере API без цели.

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

Прокси API — это управляемый фасад для серверных служб. Базовая конфигурация прокси-сервера API состоит из ProxyEndpoint (определяющего URL-адрес прокси-сервера API) и TargetEndpoint (определяющего URL-адрес серверной службы).

Apigee Edge предлагает большую гибкость для создания сложного поведения на основе этого шаблона. Например, вы можете добавить политики для управления тем, как API обрабатывает клиентский запрос перед отправкой его внутренней службе, или манипулировать ответом, полученным от внутренней службы, перед его пересылкой клиенту. Вы можете вызывать другие службы, используя политики вызова служб , добавлять собственное поведение, добавляя код Javascript , и даже создавать прокси-сервер API, который не вызывает внутреннюю службу.

Антипаттерн

Использование вызовов службы для вызова серверной службы в прокси-сервере API без маршрутов к целевой конечной точке технически осуществимо, но приводит к потере аналитических данных о производительности внешней службы.

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

Вы можете определить нулевой маршрут в прокси-сервере API, как показано здесь:

<RouteRule name="noroute"/>

Прокси-сервер, использующий нулевой маршрут, является прокси-сервером без цели, поскольку он не вызывает целевую серверную службу.

Технически возможно добавить вызов службы к прокси-серверу без целевого объекта для вызова внешней службы, как показано в примере ниже:

<!-- /antipatterns/examples/service-callout-no-target-1.xml -->
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ProxyEndpoint name="default">
    <Description/>
    <FaultRules/>
    <PreFlow name="PreFlow">
        <Request>
            <Step>
                <Name>ServiceCallout-InvokeBackend</Name>
            </Step>
        </Request>
        <Response/>
    </PreFlow>
    <PostFlow name="PostFlow">
        <Request/>
        <Response/>
    </PostFlow>
    <Flows/>
    <HTTPProxyConnection>
        <BasePath>/no-target-proxy</BasePath>
        <Properties/>
        <VirtualHost>secure</VirtualHost>
    </HTTPProxyConnection>
    <RouteRule name="noroute"/>
</ProxyEndpoint>

Однако прокси-сервер не может предоставить аналитическую информацию о поведении внешней службы (например, время обработки или частоту ошибок), что затрудняет оценку производительности внешней службы.

Влияние

  • Аналитическая информация о взаимодействии с внешним сервисом (коды ошибок, время отклика, целевая производительность и т. д.) недоступна.
  • Любая конкретная логика, необходимая до или после вызова вызова службы, включается как часть общей логики прокси, что затрудняет ее понимание и повторное использование.

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

Если прокси-сервер API взаимодействует только с одной внешней службой, прокси-сервер должен следовать базовому шаблону проектирования, в котором серверная служба определяется как целевая конечная точка прокси-сервера API. Прокси-сервер без правил маршрутизации к целевой конечной точке не должен вызывать внутреннюю службу с использованием политики ServiceCallout.

Следующая конфигурация прокси реализует то же поведение, что и пример выше, но следует лучшим практикам:

<!-- /antipatterns/examples/service-callout-no-target-2.xml -->
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ProxyEndpoint name="default">
    <Description/>
    <FaultRules/>
    <PreFlow name="PreFlow">
        <Request/>
        <Response/>
    </PreFlow>
    <PostFlow name="PostFlow">
        <Request/>
        <Response/>
    </PostFlow>
    <Flows/>
    <HTTPProxyConnection>
        <BasePath>/simple-proxy-with-route-to-backend</BasePath>
        <Properties/>
        <VirtualHost>secure</VirtualHost>
    </HTTPProxyConnection>
    <RouteRule name="default">
        <TargetEndpoint>default</TargetEndpoint>
    </RouteRule>
</ProxyEndpoint>

Используйте вызовы служб для поддержки сценариев коллажей, в которых вы хотите вызывать внешние службы до или после вызова целевой конечной точки. Вызовы служб не предназначены для замены вызова целевой конечной точки.

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