Разработка отличных возможностей для разработчиков API с помощью Управление API и GitHub

Служба приложений Azure
Приватный канал Azure
Виртуальная сеть Azure

Как издатель API, вам нужен веб-сайт, который эффективно рынки API и помогает клиентам различать предложения. Если они выбрали API, необходимо иметь возможность предоставлять доступ только для пользователей, прошедших проверку подлинности, управлять потреблением и доставлять точные счета для использования. В этом примере показано, как использовать службу Azure и GitHub для создания платформы, которая делает все это и многое другое.

Архитектура

Схема компонентов этой архитектуры и рабочего процесса через интернет-порталы и службы Azure, которые представляют собой решение, включая Microsoft Entra B 2 C, Управление I P Azure, шлюз A I И И и бизнес-службы.

Скачайте файл PowerPoint этой архитектуры.

Поток данных

Решение в основном состоит из следующих стандартных блоков:

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

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

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

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

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

Ниже приведены этапы последовательности обработки в этом решении.

  1. Издатель API импортирует спецификации API с помощью портал Azure, группирует их по продукту и публикует их.

  2. Издатель API обновляет маркетинговые сведения, связанные с продуктом, в соответствующем репозитории GitHub.

  3. Потребитель API обращается к порталу Marketplace, просматривает различные продукты и выбирает определенную службу API.

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

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

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

  7. Потребитель использует службу API в своих приложениях или устройствах.

  8. Вызов API создает метрики об использовании и использовании, которые хранятся в базах данных отслеживания Azure.

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

  10. Внутреннее задание вычисляет расходы из данных потребления и различных подписок.

  11. Сведения о счете и платеже хранятся в базе данных учета. Эта информация используется для вычисления дохода для службы.

Компоненты

Решение состоит из следующих предложений программного обеспечения как услуги (SaaS):

  • Azure Управление API — это управляемая платформа как услуга, которая позволяет организациям публиковать API как для внутренних, так и для внешних потребителей. С помощью Управление API можно публиковать API-интерфейсы, которые могут размещаться в любом месте. В основном Управление API позволяет отсогласить размещение API с опубликованного шлюза, который выступает в качестве точки единого входа для полного ландшафта API, публикуемых вашим предприятием. Дополнительные сведения см. в разделе "Шаблон маршрутизации шлюза".

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

  • GitHub — это популярное предложение SaaS от Корпорации Майкрософт, которое часто используется разработчиками для создания, отправки и обслуживания своих проектов программного обеспечения. Он предоставляет важные функции, которые можно использовать в решениях:

  • служба приложение Azure — это полностью управляемая платформа вычислений для размещения пользовательских веб-приложений.

  • Azure Active Directory (Azure AD) B2C — это расширение идентификатора Microsoft Entra, которое приложение может использовать для управления внешними удостоверениями клиентов или партнеров для доступа и авторизации. Вы можете использовать платформу идентификации Майкрософт для легкой интеграции удостоверений и авторизации в пользовательских приложениях.

Подробности сценария

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

Потенциальные варианты использования

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

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

Цепочка значений API

Схема, описывающая цепочку значений P I.

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

Интерфейс разработчика API

Схема функций и возможностей расширенного интерфейса разработчика A P I.

Скачайте файл PowerPoint этой схемы.

Интерфейс разработчика API включает три портала:

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

  • Портал разработчика. Портал разработчиков предоставляет сторонним разработчикам документацию по различным службам API и их использованию в своих приложениях.

  • Портал учетной записи. Зарегистрированные пользователи управляют подписками и выполняют другие действия, связанные с учетной записью, с помощью портала учетной записи.

Функциональные требования

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

Схема с тремя широкими функциональными требованиями корпоративной платформы A P I.

В следующих разделах описаны возможности в каждой области компонентов.

Продуктизация

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

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

Продуктизация состоит из следующих возможностей:

  • Продукты API. Этот каталог API предоставляется потребителям. Продукт может быть предложен для покупки или в качестве бесплатной службы.

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

  • Планы ценообразования. Определите различные планы ценообразования, чтобы сделать его привлекательным для потребителей.

  • Таксономия и содержимое. Определите и создайте содержимое — текстовые, PDF-файлы, изображения и т. д., необходимые для маркетинговой стратегии для этих продуктов API.

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

Администрирование платформы

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

Администрирование платформы состоит из следующих возможностей:

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

  • Каталог API. Определите ресурсы API, опубликованные с помощью Управление API. Применение политик для управления доступом и использованием API. Управление подписками пользователей.

  • Аналитика и аналитика. Запись данных телеметрии для создания различных метрик. Визуализировать данные с помощью различных панелей мониторинга, таких как Power BI, для получения различных аналитических сведений, необходимых для принятия решений для бизнеса и ИТ-специалистов.

  • Выставление счетов и выставление счетов. Определите рабочие процессы, связанные с подписками, управлением заказами, выставлением счетов и выставлением счетов.

  • Поддержка. Создайте средства и процессы для обработки запросов на поддержку.

Взаимодействие с потребителем

Внедрение платформы API сильно зависит от того, насколько легко потребители могут:

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

Взаимодействие с потребителем обычно предоставляется через веб-портал, мобильное приложение или оба. Azure AD B2C можно использовать для упрощения регистрации пользователей и управления удостоверениями. Azure AD B2C включает поддержку поставщиков удостоверений OpenID, таких как Майкрософт и Google.

Взаимодействие с потребителями состоит из следующих компонентов:

  • Каталог продуктов (API). Создайте интерфейс Marketplace для пользователей, как анонимных, так и зарегистрированных.

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

  • Пользовательский интерфейс (ПОЛЬЗОВАТЕЛЬСКИЙ интерфейс) / Взаимодействие с пользователем (UX). Определите и определите интерфейсы для каналов, которые вы поддерживаете для взаимодействия с конечными пользователями. Включите возможности нескольких устройств, многофакторных фабрик, а также современный дизайн пользовательского интерфейса. Обогащение опыта с помощью исследований удобства использования.

Рекомендации

Эти рекомендации реализуют основные принципы платформы Azure Well-Architected Framework, которая представляет собой набор руководящих принципов, которые можно использовать для повышения качества рабочей нагрузки. Дополнительные сведения см. в статье Microsoft Azure Well-Architected Framework.

Компоненты в этом сценарии устраняют проблемы производительности, надежности и безопасности.

Управление API поддерживает автоматическое масштабирование, которое быстро расширяет Управление API возможности в ответ на растущее число входящих запросов. Управление API также поддерживает избыточность зон и развертывания в нескольких регионах для обеспечения устойчивости и высокой доступности. Дополнительные сведения о избыточности зоны см. в статье о поддержке зоны доступности для Azure Управление API. Дополнительные сведения о безопасности Управление API см. в разделе "Базовые показатели безопасности Azure" для Управление API.

Служба приложений — это полностью управляемая платформа в качестве службы, которая включает встроенную безопасность и автомасштабирование с помощью функции Соглашение об уровне обслуживания, которое обещает высокий уровень доступности. Служба приложенийISO, SOC и PCI совместимы, и он поддерживает проверку подлинности пользователей с помощью идентификатора Microsoft Entra, Google, Facebook, Twitter или учетной записи Майкрософт. С помощью Служба приложений можно также создавать ограничения IP-адресов.

Azure AD B2C предлагает высокий уровень доступности и масштабирование для поддержки сотен миллионов пользователей. Azure AD B2C поддерживает OpenID Connect и несколько поставщиков удостоверений, чтобы клиенты могли выбрать предпочитаемого поставщика. Azure AD B2C также поддерживает многофакторную проверку подлинности на основе приложений и политики, добавляя дополнительные уровни безопасности. Дополнительные сведения о Azure AD B2C см. в статье "Что такое Azure Active Directory B2C?" Дополнительные сведения об использовании внешних удостоверений см. в разделе "Внешние удостоверения" в идентификаторе Microsoft Entra.

GitHub делает проверки безопасности автоматизированной частью проверок кода, сканируя каждую новую фиксацию для потенциальных проблем безопасности. Эта служба помогает обнаруживать проблемы, как только они предлагаются в качестве дополнения к базе кода. Безопасность GitHub позволяет настраивать поиск проблем безопасности и интегрировать сторонние механизмы сканирования. Дополнительные сведения см. в разделе "Безопасность " на сайте GitHub.

Оптимизация затрат

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

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

Для Управление API можно использовать уровни "Стандартный" или "Премиум". Чтобы лучше понять различия между уровнями, ознакомьтесь с Управление API вариантами ценообразования.

Сведения о приложение Azure службе см. в ценах, доступных для сред Windows и Linux для размещения приложений.

Соавторы

Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участниками.

Автор субъекта:

  • Subhajit Chatterjee | Главный инженер по программному обеспечению, отраслевые облака

Следующие шаги