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

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

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

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

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

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

Продукт Имя пользовательского интерфейса URL-адрес доступа
Край Пограничный интерфейс

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

https://apigee.com/edge

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

Edge для частного облака Классический интерфейс 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

Многие ресурсы ограничены средой. По умолчанию предоставляются две среды: test и prod. Например, область кэшей определяется средой. Общий кеш под названием «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» .

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

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

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

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

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

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

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

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

  • /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

Выполнение команд скручивания

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

Вызовы API поддерживают сжатие ответов gzip. Если вы установите 'Accept-Encoding: gzip, deflate' в вызовах API, любой ответ размером более 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, вы можете использовать библиотеку 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 используйте 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 в среде «prod», чтобы сделать их общедоступными для разработчиков приложений.

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

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

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

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

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

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

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

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