Антипаттерн: вызов вызовов Management API из прокси-сервера API

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

Edge имеет мощную утилиту под названием «API управления», которая предлагает такие услуги, как:

  • Развертывание или отмена прокси-серверов API
  • Настройка виртуальных хостов, хранилищ ключей и доверенных сертификатов и т. д.
  • Создание, удаление и/или обновление сущностей, таких как KeyValueMaps, продукты API, приложения для разработчиков, разработчики, потребительские ключи и т. д.
  • Получение информации об этих объектах

Доступ к этим службам осуществляется через компонент Management Server на платформе Apigee Edge. Эти службы можно легко вызвать с помощью простых вызовов API управления.

Иногда нам может потребоваться использовать одну или несколько этих служб из прокси-серверов API во время выполнения. Это связано с тем, что такие сущности, как KeyValueMaps, токены доступа OAuth, продукты API, приложения для разработчиков, разработчики, потребительские ключи и т. д., содержат полезную информацию в форме пар ключ-значение, настраиваемых атрибутов или как часть своего профиля.

Например, вы можете сохранить следующую информацию в KeyValueMap, чтобы сделать ее более безопасной и доступной во время выполнения:

  • Внутренние целевые URL-адреса
  • Свойства среды
  • Учетные данные безопасности серверных или сторонних систем

Аналогично, вы можете захотеть получить список продуктов API или адрес электронной почты разработчика во время выполнения. Эта информация будет доступна в профиле приложений разработчика.

Всю эту информацию можно эффективно использовать во время выполнения для обеспечения динамического поведения в политиках или пользовательском коде в Apigee Edge.

Антипаттерн

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

  • Использование API управления для доступа к информации об объектах, таких как KeyValueMaps, токены доступа OAuth или для любых других целей, из прокси-серверов API, приводит к зависимости от серверов управления.
  • Серверы управления не являются частью компонента среды выполнения Edge и поэтому могут не обеспечивать высокую доступность.
  • Серверы управления также не могут быть предоставлены в одной сети или центре обработки данных и, следовательно, могут вызывать задержки в сети во время выполнения.
  • Записи на серверах управления кэшируются на более длительный период времени, поэтому мы не сможем сразу увидеть последние данные в прокси-серверах API, если будем выполнять запись и чтение за короткий период времени.
  • Увеличивает количество сетевых переходов во время выполнения.

В приведенном ниже примере кода вызов API управления выполняется через собственный код JavaScript для получения информации из KeyValueMap:

var response = httpClient.send('https://api.enterprise.apigee.com/v1/o/org_name/e/env_name/keyvaluemaps/kvm_name')

Если сервер управления недоступен, код JavaScript, вызывающий вызов API управления, завершается сбоем. Впоследствии это приводит к сбою запроса API.

Влияние

  • Вводит дополнительную зависимость от серверов управления во время выполнения. Любой сбой на серверах управления повлияет на вызовы API.
  • Учетные данные пользователя для API управления необходимо хранить либо локально, либо в каком-либо безопасном хранилище, например Encrypted KVM.
  • Влияние на производительность из-за вызова службы управления по сети.
  • Обновленные значения могут отображаться не сразу из-за более длительного срока действия кэша на серверах управления.

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

Существуют более эффективные способы получения информации от таких объектов, как KeyValueMaps, продукты API, DeveloperApps, Developers, Consumer Keys и т. д. во время выполнения. Вот несколько примеров:

  • Используйте политику KeyValueMapOperations для доступа к информации из KeyValueMaps. Вот пример кода, показывающий, как получить информацию из KeyValueMap: 
    <!-- /antipatterns/examples/2-6.xml -->
<KeyValueMapOperations mapIdentifier="urlMap" async="false"
    continueOnError="false" enabled="true" name="GetURLKVM">
  <DisplayName>GetURLKVM</DisplayName>
  <ExpiryTimeInSecs>86400</ExpiryTimeInSecs>
  <Scope>environment</Scope>
  <Get assignTo="urlHosti" index="2">
    <Key>
      <Parameter>urlHost_1</Parameter>
    </Key>
  </Get>
</KeyValueMapOperations>
  • Чтобы получить доступ к информации о продуктах API, приложениях для разработчиков, разработчиках, потребительских ключах и т. д. в прокси-сервере API, вы можете выполнить одно из следующих действий:
    • Если ваш поток прокси-сервера API имеет политику VerifyAPIKey , вы можете получить доступ к информации, используя переменные потока, заполненные как часть этой политики. Вот пример кода, который показывает, как получить имя и информацию о созданном_приложении разработчика с помощью JavaScript: 
      <!-- /antipatterns/examples/2-7.xml -->
print("Application Name ", context.getVariable(""verifyapikey. VerifyAPIKey.app.name"));
print("Created by:", context.getVariable("verifyapikey. VerifyAPIKey.app.created_by"));
    • Если в вашем потоке прокси-сервера API нет политики VerifyAPIKey, вы можете получить доступ к профилям продуктов API, приложений для разработчиков и т. д. с помощью политик доступа к сущности и извлечения переменных:
      1. Получите профиль DeveloperApp с политикой AccessEntity : 
        <!-- /antipatterns/examples/2-8.xml -->
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<AccessEntity async="false" continueOnError="false" enabled="true" name="GetDeveloperApp">
  <DisplayName>GetDeveloperApp</DisplayName>
  <EntityType value="app"></EntityType>
  <EntityIdentifier ref="developer.app.name" type="appname"/>
  <SecondaryIdentifier ref="developer.id" type="developerid"/>
</AccessEntity>
      2. Извлеките appId из DeveloperApp с помощью политики ExtractVariables : 
        <!-- /antipatterns/examples/2-9.xml -->
<ExtractVariables name="Extract-Developer App-Info">
  <!--
    The source element points to the variable populated by AccessEntity policy.
    The format is <policy-type>.<policy-name>
    In this case, the variable contains the whole developer profile.
  -->
  <Source>AccessEntity.GetDeveloperApp"</Source>
  <VariablePrefix>developerapp</VariablePrefix>
  <XMLPayload>
    <Variable name="appld" type="string">
      <!-- You parse elements from the developer profile using XPath. -->
      <XPath>/App/AppId</XPath>
    </Variable>
  </XMLPayload>
</ExtractVariables>

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