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

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

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

Используйте интерфейс Edge.

Apigee Edge UI — это браузерный инструмент, который можно использовать для создания, настройки и управления API-прокси и API-продуктами. Часть задач также может быть выполнена только с помощью API.

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

Продукт Название пользовательского интерфейса URL-адрес доступа
Край Edge UI

Для доступа к пользовательскому интерфейсу 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

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

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

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

Разберитесь в базовом пути API Edge.

Путь, который вы будете использовать в запросах 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 для ресурса кэша следующим образом:

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 .

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

В этом разделе описаны некоторые методы, упрощающие работу с 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

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

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

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

По умолчанию API Edge возвращает данные в формате 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 . В результате, с помощью acurl вы можете получать ответы только в формате JSON.

Для использования prettyprint при обработке JSON-ответа можно воспользоваться библиотекой Python json.tool : 

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 методом POST или PUT используйте 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: «тестовая» и «производственная». Используйте среду «тестовая» для разработки и тестирования ваших API, прежде чем делать их общедоступными. Доступ к API, развернутым в тестовой среде, имеют только ваши внутренние разработчики. Разверните ваши API в среде «производственная», чтобы сделать их общедоступными для разработчиков приложений.

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

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

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

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

На следующем рисунке показаны результаты трассировки:

Отображает вкладку «Трассировка», выбранную в редакторе API-прокси в пользовательском интерфейсе Edge.

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

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