Вы просматриваете документацию Apigee Edge .
Перейдите к документации Apigee X. информация
В следующих разделах вы познакомитесь с продуктами API и связанными с ними ключевыми понятиями .
Что такое продукт API?
Как поставщик API вы создаете продукты API, объединяющие ваши API и предоставляющие их разработчикам приложений для использования. Вы можете думать о продуктах API как о своей линейке продуктов.
В частности, продукт API объединяет следующее:
- Сбор ресурсов API (URI)
- План обслуживания
- Метаданные, специфичные для вашего бизнеса, для мониторинга или аналитики (необязательно)
Ресурсы API, включенные в продукт API, могут поступать из одного или нескольких API, поэтому вы можете смешивать и сопоставлять ресурсы для создания специализированных наборов функций, как показано на следующем рисунке.
Вы можете создать несколько продуктов API для решения конкретных задач. Например, вы можете создать продукт API, который объединяет ряд картографических ресурсов, чтобы разработчики могли легко интегрировать карты в свои приложения. Кроме того, вы можете установить разные свойства для каждого продукта API, например разные уровни цен. Например, вы можете предложить следующие комбинации продуктов API:
- Продукт API, предлагающий низкий лимит доступа, например 1000 запросов в день, по выгодной цене. Второй продукт API, обеспечивающий доступ к тем же ресурсам, но с более высоким лимитом доступа и более высокой ценой.
- Бесплатный продукт API, предлагающий доступ к ресурсам только для чтения. Второй продукт API, обеспечивающий доступ для чтения и записи к тем же ресурсам за небольшую плату.
Кроме того, вы можете контролировать доступ к ресурсам API в продукте API. Например, вы можете объединить ресурсы, доступ к которым будут иметь только внутренние разработчики или только платящие клиенты.
Продукты API — это центральный механизм авторизации и контроля доступа к вашим API. В Apigee ключи API предоставляются не для самих API, а для продуктов API. Другими словами, ключи API предоставляются для пакетов ресурсов с прикрепленным планом обслуживания.
Разработчики приложений получают доступ к вашим продуктам API, регистрируя свои приложения, как описано в разделе Регистрация приложений. Когда приложение пытается получить доступ к продукту API, Apigee обеспечивает авторизацию во время выполнения, чтобы гарантировать, что:
- Запрашивающему приложению разрешен доступ к определенному ресурсу API.
- Запрашивающее приложение не превысило разрешенную квоту.
- Если определено, области OAuth, определенные в продукте API, соответствуют тем, которые связаны с токеном доступа, представленным приложением.
Понимание ключевых концепций
Прежде чем создавать продукты API, ознакомьтесь со следующими ключевыми понятиями.
Ключи API
Когда вы регистрируете приложение разработчика в своей организации, оно должно быть связано хотя бы с одним продуктом API. В результате сопряжения приложения с одним или несколькими продуктами API Edge назначает приложению уникальный потребительский ключ.
Ключ потребителя или токен доступа действуют как учетные данные запроса. Разработчик приложения встраивает потребительский ключ в приложение, поэтому, когда приложение отправляет запрос к API, размещенному в Edge, приложение передает потребительский ключ в запросе одним из следующих способов:
- Когда API использует проверку ключа API, приложение должно напрямую передать ключ потребителя.
- Когда API использует проверку токена OAuth, приложение должно передать токен, полученный из ключа потребителя.
Применение ключей API не происходит автоматически. Независимо от того, используете ли ключ потребителя или токены OAuth в качестве учетных данных запроса, прокси-сервер API проверяет учетные данные запроса в ваших прокси-серверах API, включая политику VerifyAPIKey или политику OAuth/VerifyAccessToken в соответствующий поток. Если вы не включите политику принудительного использования учетных данных в свой прокси-сервер API, любой вызывающий объект сможет вызывать ваши API. Дополнительную информацию см. в разделе «Проверка политики ключей API» .
Чтобы проверить учетные данные, переданные в запросе, Edge выполняет следующие шаги:
- Получите учетные данные, переданные вместе с запросом. В случае проверки токена OAuth Edge проверяет, не истек ли срок действия токена, а затем ищет потребительский ключ, который использовался для создания токена.
- Получите список продуктов API, с которыми связан потребительский ключ.
- Убедитесь, что текущий прокси-сервер API включен в продукт API и включен ли текущий путь к ресурсу (путь URL-адреса) в продукте API.
- Убедитесь, что срок действия потребительского ключа не истек и не отозван, убедитесь, что приложение не отозвано, и убедитесь, что разработчик приложения активен.
Если все вышеперечисленные проверки пройдены, проверка учетных данных завершится успешно.
В итоге Edge автоматически генерирует потребительские ключи, но издатели API должны обеспечивать проверку ключей в прокси-серверах API, используя соответствующие политики.
Автоматическое и ручное одобрение
По умолчанию все запросы на получение ключа для доступа к продукту API из приложения утверждаются автоматически. Кроме того, вы можете настроить продукт API для утверждения ключей вручную. В этом случае вам придется утвердить запросы ключей от любого приложения, которое добавляет продукт API. Дополнительные сведения см. в разделе Регистрация приложений и управление ключами API .
Квоты
Квоты могут защитить ваши серверные серверы от высокого трафика и дифференцировать вашу линейку продуктов. Например, вы можете объединить ресурсы с высокой квотой в качестве продукта премиум-класса и использовать тот же пакет с более низкой квотой в качестве базового продукта. Квота может помочь защитить ваши серверы от перегрузки, если продукт популярен и получает большое количество запросов.
Информацию о настройке квот см. в разделе Политика квот . Информацию об использовании настроек квот продукта в политиках квот см. в следующей статье сообщества . Как настройки квот продукта API взаимодействуют с политиками квот в прокси-сервере API? .
Области действия OAuth
В качестве дополнительного уровня безопасности вы можете определить любые области OAuth в виде списка, разделенного запятыми, которые должны присутствовать в токенах доступа, отправляемых через продукт. Когда вы создаете продукт, вам необходимо знать обо всех областях, которые использует ваша организация. Области, которые вы добавляете в продукт, должны соответствовать существующим областям, иначе продукт небезопасен.
Дополнительные сведения об использовании областей с политиками Edge OAuth см. в разделе Работа с областями OAuth2 .
Уровни доступа
При определении продукта API вы можете установить следующие уровни доступа.
| Уровень доступа | Описание |
|---|---|
| Общественный | Продукты API, доступные всем разработчикам. Вы можете добавить их на интегрированные порталы разработчиков или порталы разработчиков на базе Drupal. |
| Только частный или внутренний | Продукты API, предназначенные для частного или внутреннего использования. Примечание. Функциональной разницы между уровнями доступа «Частный» и «Только внутренний» нет. Выберите ярлык, который лучше всего описывает целевую аудиторию продукта API. Для интегрированного портала вы можете добавить частные или только внутренние продукты API и сделать их доступными для разработчиков приложений по мере необходимости. Для порталов разработчиков на базе Drupal вы можете управлять доступом к частным или внутренним продуктам API на своем портале разработчика, как описано в следующих разделах:
|