Жизненный цикл разработки API

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

Каждая организация имеет уникальный жизненный цикл разработки программного обеспечения (SDLC). Часто бывает необходимо синхронизировать и согласовать развертывание прокси-сервера API с теми же процессами, которые вы используете сегодня для разработки, тестирования и развертывания других приложений.

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

API-интерфейсы служб API описаны в справочнике по API. См. справку по API «Начало работы» .

Посмотрите это видео, чтобы познакомиться со средами API и жизненным циклом разработки API.

Окружающая среда

В каждой организации, использующей Apigee Edge, имеется как минимум две среды развертывания, доступные для прокси-серверов API: «тестовая» и «производительная». Различие между двумя средами произвольно — каждая среда просто идентифицируется своим набором сетевых адресов (URL). Цель — предоставить вам домен, в котором вы сможете создавать и проверять прокси-серверы API до того, как API станет доступен внешним разработчикам.

Вы можете использовать эти среды для синхронизации разработки прокси-сервера API с вашим SDLC. Каждая среда определяется сетевым адресом, что позволяет вам разделить трафик между прокси-серверами API, над которыми вы работаете, и теми, к которым приложения обращаются во время выполнения. Сетевые адреса, доступные для каждой среды, определяются в наборе виртуальных хостов, доступных в этой среде.

Входящий серверный TLS/SSL автоматически включается для каждой среды. В каждой среде предопределены два виртуальных хоста: default и secure . Значение по умолчанию определяет адрес HTTP, а значение безопасности определяет адрес HTTP/S с предварительно настроенным TLS/SSL на стороне сервера. В конфигурации прокси-сервера API вы указываете, какие виртуальные хосты должен прослушивать ProxyEndpoint. При переходе на продукт вы обычно отключаете HTTP, удаляя VirtualHost default из конфигурации прокси-сервера API.

Например, следующая ProxyEndpoint прослушивает HTTP и HTTPS.

<HTTPProxyConnection>
  <BasePath>/v0/weather</BasePath>
  <Properties/>
  <VirtualHost>default</VirtualHost>
  <VirtualHost>secure</VirtualHost>
</HTTPProxyConnection>

Удаляя VirtualHost default из конфигурации ProxyEndpoint, вы создаете прокси-сервер API, который прослушивает только HTTPS, а не HTTP.

<HTTPProxyConnection>
  <BasePath>/v0/weather</BasePath>
  <Properties/>
  <VirtualHost>secure</VirtualHost>
</HTTPProxyConnection>

Вы можете увидеть, какие виртуальные хосты доступны в среде, выбрав «Среды» в главном меню пользовательского интерфейса управления.

Среды также обеспечивают разделение данных и ресурсов. Например, вы можете настроить разные кеши в test и prod, доступ к которым будет возможен только через прокси-серверы API, выполняющиеся в этой среде. Кроме того, ключи API, выданные в тестовой среде, недействительны в рабочей среде, и наоборот.

Развертывание прокси API в средах

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

Дополнительные сведения см. в разделе Общие сведения о развертывании .

Итеративная разработка в тесте

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

Продвижение в прод.

Когда прокси-сервер API полностью реализован и протестирован, его можно повысить до уровня «Prod». Версия прокси-сервера API в тесте будет использоваться для перезаписи версии прокси-сервера API, развернутого на рабочей версии.

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

Развертывание сценариев

Пользовательский интерфейс управления Apigee Edge позволяет развертывать прокси API для работы непосредственно из конструктора прокси API. Однако во многих ситуациях требования к безопасности, надежности и согласованности требуют от команд разработчиков сценариев развертывания. Для этого вы можете написать код и сценарии, которые вызывают API RESTful, предоставляемый службами API.

Ресурсы окружающей среды

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

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

  • Целевые URL-адреса. Прокси-серверы API часто вызывают разные внутренние URL-адреса во время тестирования и производства. Вы можете использовать конфигурации TargetServer для создания независимых от среды конфигураций TargetEndpoint. См. Балансировка нагрузки на внутренних серверах .
  • Кэши и карты «ключ-значение». Оба ресурса сохраняемости определяются средой. Вы должны убедиться, что используются соглашения об именах, позволяющие прокси-серверам API хранить данные без необходимости изменения конфигурации во время продвижения. См. Создание и редактирование кэша среды .
  • Цели ServiceCallout: вызовы службы могут использовать разные цели в зависимости от среды, если, например, ServiceCallout в тестовой среде использует демонстрационную службу. См. политику вызова сервисных служб .

Чтобы сделать конфигурации прокси-сервера API независимыми от среды, вы также можете использовать условные операторы. Условный оператор, созданный с помощью переменной environment.name , можно использовать для оценки текущей среды перед применением политики или перед маршрутизацией на URL-адрес на серверной стороне.

Дополнительные сведения см. в разделе Общие сведения о развертывании .