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