Эта страница переведена с помощью Cloud Translation API.

Что такое Апигей Эдж?

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

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

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

Создайте свой первый прокси!

Цифровое ускорение

Это видео дает вам краткое представление о том, как Apigee помогает вам развиваться в цифровом бизнесе.

Выбор между управлением сервисами и управлением API

Это видео поможет вам понять важные различия между управлением сервисами и управлением API. бизнес.

Сделайте ваши услуги доступными в Интернете

Сегодня компании хотят сделать свои серверные службы доступными в Интернете, чтобы эти службы могли использоваться приложениями, работающими на мобильных устройствах и настольных компьютерах. Компания может захотеть предоставить услуги, которые предоставляют информацию о ценах и наличии продуктов, услуги продаж и заказов, службы отслеживания заказов и любые другие службы, необходимые клиентским приложениям.

Компании часто представляют службы как набор конечных точек HTTP. Затем разработчики клиентских приложений отправляют HTTP-запросы к этим конечным точкам. В зависимости от конечной точки служба может затем вернуть данные в формате XML или JSON обратно в клиентское приложение.

Клиентские приложения, использующие эти службы, могут быть реализованы как автономные приложения для мобильного устройства или планшета, как приложения HTML5, работающие в браузере, или как приложения любого другого типа, которые могут отправлять запросы к конечной точке HTTP и использовать любые данные ответа. Эти приложения могут быть разработаны и выпущены той же компанией, которая предоставила эти услуги, или сторонними разработчиками приложений, которые используют общедоступные службы.

На следующем изображении показан этот тип модели:

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

Поскольку поставщики предоставляют свои услуги через Интернет, они должны убедиться, что предприняли все необходимые шаги для защиты своих услуг от несанкционированного доступа. Будучи поставщиком услуг, рассмотрите:

Безопасность. Как вы будете контролировать доступ к вашим сервисам, чтобы предотвратить несанкционированный доступ?
Совместимость. Будут ли ваши сервисы работать на разных платформах и устройствах?
Измеримость: как вы можете контролировать свои услуги, чтобы быть уверенными в их доступности?
Монетизация: как вы можете отслеживать и выставлять счета клиентам за доступ к вашим услугам?
И многие другие соображения

После выпуска клиентского приложения, которое получает доступ к каким-либо службам, поставщик услуг должен убедиться, что эти службы продолжают работать с течением времени при добавлении, изменении или удалении этих служб. У поставщика услуг также должен быть способ информировать разработчиков приложений о любых изменениях в службах, чтобы гарантировать синхронизацию клиентских приложений с этими службами.

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

Сделайте услуги доступными через Apigee Edge

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

Упрощает использование ваших услуг разработчиками приложений.
Позволяет изменить реализацию серверной службы, не затрагивая общедоступный API.
Позволяет вам воспользоваться преимуществами аналитики, монетизации, портала разработчиков и других функций, встроенных в Edge.

На следующем изображении показана архитектура, в которой Edge обрабатывает запросы от клиентских приложений к вашим серверным службам:

Apigee Edge находится между клиентскими приложениями и серверными службами.

Вместо того, чтобы заставлять разработчиков приложений напрямую использовать ваши сервисы, они получают доступ к прокси-серверу API, созданному в Edge. Прокси-сервер API выполняет функцию сопоставления общедоступной конечной точки HTTP с вашей внутренней службой. Создавая прокси-сервер API, вы позволяете Edge выполнять задачи безопасности и авторизации, необходимые для защиты ваших сервисов, а также анализировать, отслеживать и монетизировать эти сервисы.

Поскольку разработчики приложений отправляют HTTP-запросы к прокси-серверу API, а не напрямую к вашим сервисам, разработчикам не нужно ничего знать о реализации ваших сервисов. Все, что нужно знать разработчику:

URL-адрес конечной точки прокси-сервера API.
Любые параметры запроса, заголовки или параметры тела, передаваемые в запросе.
Любые необходимые учетные данные для аутентификации и авторизации.
Формат ответа, включая формат данных ответа, например XML или JSON.

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

Вы можете использовать политики прокси-сервера API, чтобы добавить функциональность службе без необходимости внесения каких-либо изменений во внутреннюю службу. Например, вы можете добавить политики к своему прокси-серверу для выполнения преобразований и фильтрации данных, повышения безопасности, выполнения условной логики или пользовательского кода, а также для выполнения многих других действий. Важно помнить: вы реализуете политики на Edge, а не на своем внутреннем сервере.

Дополнительные сведения см. в разделе Общие сведения об API и прокси-серверах API .

Создать продукт API

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

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

У вас есть большая гибкость при создании продуктов API. Например, несколько продуктов API могут использовать один и тот же прокси-сервер API. На следующем рисунке показаны три продукта API. Обратите внимание, что все продукты разрешают доступ к прокси-серверу API 3, но только продукт A разрешает доступ к прокси-серверу API 1.

Продукт A обращается к прокси-серверу 1 и 3. Продукт B обращается к прокси-серверу 3. Продукт C обращается к прокси-серверу 2, 3 и 4.

Вы можете установить разные свойства для каждого продукта API. Например, вы можете предоставить один продукт API с низким лимитом доступа, например 1000 запросов в день, по выгодной цене. Затем вы выпускаете другой продукт API, который обеспечивает доступ к тому же прокси-серверу API, но с гораздо более высоким лимитом доступа и по более высокой цене. Или вы можете создать бесплатный продукт API, который обеспечивает доступ к вашим сервисам только для чтения, а затем продавать продукт API тем же прокси-серверам API, которые разрешают доступ для чтения и записи.

Дополнительную информацию см. в разделе «Управление продуктами API» .

Разрешите клиентскому приложению доступ к вашему продукту API

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

Клиентскому приложению необходим ключ для вызова API, связанного с продуктом API.

После регистрации разработчик приложения получает ключ API, который он затем должен включать в каждый запрос к прокси-серверу API, включенному в продукт API. Этот ключ аутентифицирован, и если аутентификация прошла успешно, запросу будет разрешен доступ к вашей внутренней службе.

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

Вы сами решаете, как обрабатывать запросы на регистрацию от разработчиков для доступа к вашим продуктам API. Используя Apigee Edge Developer Services, вы можете автоматизировать процесс регистрации; или вы можете использовать ручной процесс для контроля доступа.

Создавайте продукты API и делайте их доступными для разработчиков.

Создайте один или несколько прокси-серверов API, которые сопоставляют общедоступные URL-адреса с вашими серверными службами.
Создайте продукт API, который объединяет ваши прокси API.
Разверните свои прокси-серверы API и продукт API.
Сообщите своим разработчикам, что продукт API доступен.

Как только разработчики приложений узнают о доступности вашего продукта API, они:

Зарегистрируйте их клиентские приложения с помощью вашего продукта API.
Получите ключ API для продукта API.
Делайте запросы к своим сервисам через прокси-серверы API (которые включены в продукт API) и передавайте ключ API с каждым запросом.

Компоненты Apigee Edge

Apigee Edge состоит из среды выполнения API, средств мониторинга и аналитики, а также услуг для разработчиков, которые вместе обеспечивают комплексную инфраструктуру для создания, безопасности, управления и эксплуатации API.

На следующем рисунке показаны службы Edge:

Среда выполнения Edge API

Службы API Apigee Edge предназначены для создания и использования API, независимо от того, создаете ли вы прокси-серверы API в качестве поставщика услуг или используете API, SDK и другие удобные сервисы в качестве разработчика приложений.

Сервер управления API предоставляет инструменты для добавления и настройки прокси-серверов API, настройки продуктов API и управления разработчиками приложений и клиентскими приложениями. Это снимает многие общие проблемы управления с ваших серверных служб. Добавляя прокси-сервер API, вы можете применять к нему политики для повышения безопасности, ограничения скорости, посредничества, кэширования и т. д. Вы также можете настроить поведение своего прокси-сервера API, применяя собственные сценарии, вызывая сторонние API и службы и т. д. Дополнительные сведения см. в разделе Общие сведения об API и прокси-серверах API .

Если вы разработчик Node.js, вы можете легко добавлять свои модули Node.js в Edge для создания API и гибридных приложений API, одновременно используя преимущества, которые предоставляет Edge: от преобразования сообщений до безопасности и аналитики.

Периферийный мониторинг и аналитика

Apigee Edge API Analytics предоставляет мощные инструменты для отслеживания краткосрочных и долгосрочных тенденций использования ваших API. Вы можете сегментировать свою аудиторию по ведущим разработчикам и приложениям, анализировать использование по методу API, чтобы знать, куда инвестировать, и создавать собственные отчеты по информации бизнес- или операционного уровня.

Когда данные проходят через Edge, собирается несколько типов информации по умолчанию, включая URL-адрес, IP-адрес, идентификатор пользователя для информации о вызовах API, задержку, данные об ошибках и т. д. Вы можете создавать политики для добавления другой информации, такой как заголовки, параметры запроса и части запроса или ответа, извлеченные из XML или JSON. Эта информация собирается асинхронно из фактического потока запросов/ответов и поэтому не влияет на производительность API.

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

Аналитическая панель, которая показывает количество ошибок политики в графической и табличной форме.

Однако вы также можете получить доступ к Службе аналитики и управлять ею с помощью интерфейса командной строки или через API-интерфейсы RESTful. Дополнительную информацию см. в обзоре API Analytics .

Экосистема разработчиков Edge

Apigee Edge предоставляет услуги для разработчиков, которые позволяют вам:

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

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

Apigee Edge позволяет создавать порталы двух типов:

Интегрированный портал , который можно мгновенно подготовить. См. раздел Создание интегрированного портала .
Портал на базе Drupal . См. раздел Создание портала на базе Drupal .

Монетизация

Возможности монетизации обеспечивают финансовую инфраструктуру и отношения, позволяющие превратить ваше сообщество разработчиков в реальный канал для ваших цифровых активов. С помощью монетизации вы можете создавать различные тарифные планы , которые взимают с разработчиков плату за использование ваших продуктов API или позволяют вам платить разработчикам в сценариях распределения доходов.

Планы включают в себя планы с предоплатой, планы с постоплатой, планы с фиксированной оплатой, планы с переменной ставкой, планы «фримиум», планы, адаптированные для конкретных разработчиков, планы, охватывающие группы разработчиков, и многое другое. Кроме того, монетизация включает в себя возможности отчетности и выставления счетов.

Дополнительную информацию см. в разделе Обзор монетизации .

Ароматы края

Apigee Edge выпускается в следующих вариантах:

Публичное облако: размещенная версия SAAS, в которой Apigee поддерживает среду, позволяя вам сосредоточиться на создании своих сервисов и определении API для этих сервисов.
Частное облако: локальная установка, при которой вы контролируете аппаратную среду и отвечаете за установку, обновление, обслуживание и другие административные процессы.

Если вас интересует наша гибридная версия Apigee, см. следующие темы Apigee X:

Функционально версии Public Cloud и Private Cloud очень похожи. Однако версия частного облака не поддерживает все функции версии публичного облака. Функции, не поддерживаемые частным облаком, включают:

Размещенные цели
Расширения
Интегрированные порталы разработчиков ( Примечание : поддерживаются порталы разработчиков на базе Drupal)
API-мониторинг
Смысл

Список различий между вкусами см. в разделе «Сравнение продуктов Apigee» .

Между API также есть незначительные различия, как описано в разделе Различия между Edge для API публичного облака и API частного облака .

Public Cloud поддерживает как бесплатные, так и платные учетные записи. Для частного облака требуются платные учетные записи.

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