Инструменты разработки

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

Как поставщик услуг, вы разрабатываете API для клиентских приложений. Чтобы создавать, настраивать и поддерживать прокси API и продукты API, вы можете использовать интерфейс или отправлять HTTP-запросы к API для доступа к сервисам RESTful, как описано в следующих разделах.

Как использовать интерфейс Edge

Интерфейс Apigee Edge – это браузерный инструмент, который можно использовать для создания, настройки и управления прокси API и продуктами API. Некоторые задачи можно выполнить только с помощью API.

В таблице ниже описано, как получить доступ к интерфейсу Edge.

Товар Название интерфейса URL доступа
Edge Интерфейс Edge

Чтобы открыть интерфейс Edge, используйте следующий URL:

https://apigee.com/edge

Учебное руководство по использованию интерфейса Edge приведено в разделе Создание первого прокси-сервера API.
Edge для частного облака Классический интерфейс Edge

Чтобы получить доступ к интерфейсу Edge для частного облака, используйте следующий URL:

http://ms-ip:9000

где ms-ip – это IP-адрес или DNS-имя узла сервера управления.

С помощью интерфейса Edge можно:

  • Создавайте прокси API, редактируя код и отслеживая потоки запросов через прокси.
  • Создавайте продукты API, которые объединяют прокси для обработки клиентских запросов.
  • управлять разработчиками и их приложениями;
  • Настройте тестовую и рабочую среды.
  • Реализуйте приложения на JavaScript и Node.js.

На изображении ниже показан редактор прокси-сервера API в интерфейсе, который можно использовать для создания и настройки прокси-сервера API:

На изображении показана вкладка "Разработка", выбранная в редакторе прокси-сервера API в интерфейсе Edge.

Как использовать Edge API

Вы можете использовать Edge API для управления ресурсами API. Кроме того, API предоставляют доступ к низкоуровневым функциям, которые недоступны в интерфейсе.

Конечные точки API часто принимают данные, содержащие информацию о конфигурации, и требуют передачи учетных данных, таких как имя пользователя и пароль, для доступа к ним. В соответствии с принципами RESTful вы можете вызывать методы HTTP GET, POST, PUT и DELETE для любого из ресурсов API.

Полный список API Apigee Edge приведен в Справочнике по API Apigee Edge.

Базовый путь Edge API

Путь, который вы будете использовать в запросах API, состоит из следующих частей:

  • Базовый путь, включающий название организации. Пример: https://api.enterprise.apigee.com/v1/organizations/org_name
  • Конечная точка, указывающая на ресурс Edge, к которому вы обращаетесь.

Например, если название вашей организации – apibuilders, то каждый вызов API будет использовать следующий базовый путь:

https://api.enterprise.apigee.com/v1/organizations/apibuilders

Чтобы получить список прокси API в организации, вызовите GET для:

https://api.enterprise.apigee.com/v1/organizations/apibuilders/apis

Многие ресурсы ограничены средой. По умолчанию предоставляются две среды: тестовая и рабочая. Например, кеширование выполняется в рамках среды. Общий кеш с названием mycache по умолчанию включен в каждую среду.

Чтобы получить список кешей, вызовите метод GET для ресурса cache, как показано ниже.

https://api.enterprise.apigee.com/v1/organizations/apibuilders/environments/test/caches
https://api.enterprise.apigee.com/v1/organizations/apibuilders/environments/prod/caches

Аутентификация доступа

При вызове API необходимо пройти аутентификацию на сервере API. Это можно сделать одним из следующих способов:

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

Ограничения API Edge

Для каждой организации действуют следующие ограничения на частоту вызовов Edge API:

  • 10 000 звонков в минуту для организаций с платными планами.
  • 600 вызовов в минуту для организаций с пробной подпиской.

Коды статуса HTTP 401 и 403 не учитываются в этом лимите. По вызовам с превышением таких лимитов будет выводиться код статуса 429 Too Many Requests.

Советы по работе с API Edge

В этом разделе описаны некоторые методы, которые упрощают работу с API Edge.

Сокращение URL запросов

При создании URL запроса к Edge API можно использовать следующие сокращения:

  • /e = /environments
  • /o = /organizations
  • /r = /revisions

Если вы используете сокращения, они должны быть одинаковыми во всех случаях. То есть сокращайте все элементы пути, как описано выше и показано в следующем примере, или не сокращайте ни одного. Если в одном пути использовать как полные, так и сокращенные элементы, возникнет ошибка.

Пример:

THIS:
https://api.enterprise.apigee.com/v1/organizations/ahamilton-eval/environments/prod/apis/helloworld/revisions/1/deployments
CAN BE MUCH SHORTER:
https://api.enterprise.apigee.com/v1/o/ahamilton-eval/e/prod/apis/helloworld/r/1/deployments

Выполнение команд curl

Используйте HTTP-клиент для отправки запросов к API. Во многих примерах в документации приведены образцы запросов API с использованием curl – широко распространенного HTTP-клиента. Если вам нужно установить curl, скачайте его с сайта http://curl.haxx.se.

Вызовы API поддерживают сжатие ответов в формате gzip. Если в вызовах API задан параметр 'Accept-Encoding: gzip, deflate', все ответы размером более 1024 байт возвращаются в формате gzip.

Форматирование запросов и ответов XML и JSON

По умолчанию Edge API возвращает данные в формате JSON. Для многих запросов можно получить ответ в формате XML. Для этого задайте для заголовка запроса Accept значение application/xml, как показано в следующем примере:

curl -H "Authorization: Bearer `get_token`" \
  -H "Accept: application/xml" \
  https://api.enterprise.apigee.com/v1/organizations/ahamilton-eval/apis/helloworld/revisions/1/policies/ \
  | xmllint --format -

Ответ должен выглядеть следующим образом:

<List>
  <Item>SOAP-Message-Validation-1</Item>
  <Item>Spike-Arrest-1</Item>
  <Item>XML-to-JSON-1</Item>
</List>

Обратите внимание, что в этом примере используется prettyprint для отображения результатов путем передачи ответа через xmllint.

Утилита acurl не поддерживает заголовок Accept. В результате вы можете получать ответы в формате JSON с acurl.

Чтобы использовать prettyprint для ответа в формате JSON, можно воспользоваться библиотекой json.tool Python:

curl https://api.enterprise.apigee.com/v1/organizations/ahamilton-eval/apis/helloworld/revisions/1/policies/ \
  -H "Accept: application/json" \
  -H "Authorization: Bearer `get_token`" \
  | python -m json.tool

Ниже приведен пример ответа.

[
  "SOAP-Message-Validation-1",
  "Spike-Arrest-1",
  "XML-to-JSON-1"
]

Для XML-файлов можно использовать xmllint:

curl https://ahamilton-eval-test.apigee.net/getstarted -u email_address | xmllint --format -

При отправке или размещении полезной нагрузки в формате XML используйте HTTP-заголовок Content-type:

acurl -H "Content-type:text/xml" -X POST -d \
'<XMLPayload>
 </XMLPayload> ' \
https://api.enterprise.apigee.com/v1/organizations/apifactory/apis -u email_address

Среды развертывания

В каждой организации, использующей Apigee Edge, по умолчанию есть как минимум две среды, которые можно использовать для разработки, тестирования и развертывания API: test и prod. Используйте тестовую среду для разработки и тестирования API, прежде чем открывать к ним общий доступ. Доступ к API, развернутым в тестовой среде, есть только у ваших внутренних разработчиков. Разверните API в среде prod, чтобы сделать их общедоступными для разработчиков приложений.

Отладка и тестирование

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

Ключевые данные для устранения неполадок:

  • Временные метки. Показывают, сколько времени занимает каждый шаг. Сравнивая временные метки, вы можете определить, какие правила выполняются дольше всего и замедляют вызовы API.
  • Базовый путь. Проверив базовый путь, вы можете убедиться, что правило направляет письмо на нужный сервер.
  • Результаты выполнения правил. Эти результаты позволяют узнать, изменяется ли сообщение нужным образом, например преобразуется ли оно из XML в JSON или кешируется ли оно.

На рисунке ниже показаны результаты трассировки.

На изображении показана вкладка Trace, выбранная в редакторе прокси-сервера API в интерфейсе Edge.

Каждая сессия трассировки состоит из следующих основных этапов:

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