Вы просматриваете документацию по 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 в виде списка, разделенного запятыми, которые должны присутствовать в токенах доступа, отправляемых через продукт. При создании продукта необходимо учитывать все области действия, которые использует ваша организация. Области действия, добавленные в продукт, должны совпадать с существующими областями действия, иначе продукт будет небезопасным.
Подробнее о том, как использовать области действия с правилами OAuth в Edge…
Уровни доступа
При определении продукта API можно задать следующие уровни доступа:
| Уровень доступа | Описание |
|---|---|
| Для всех | Продукты API, доступные всем разработчикам. Вы можете добавить их в интегрированные порталы для разработчиков или порталы на основе Drupal. |
| Частный или только для внутреннего использования | Продукты API, предназначенные для частного или внутреннего использования. Примечание. Уровни доступа "Частный" и "Внутренний" ничем не отличаются. Выберите ярлык, который лучше всего описывает целевую аудиторию продукта API. На интегрированном портале можно добавлять частные или внутренние продукты API и предоставлять их разработчикам приложений по мере необходимости. Если ваш портал для разработчиков создан на основе Drupal, вы можете управлять доступом к частным или внутренним продуктам API на портале для разработчиков, как описано в следующих разделах:
|