Azure Api Management
Уже достаточно давно в Microsoft Azure в preview находится сервис Api Management. На Хабре его анонсировали в мае.ИдеяMicrosoft, как всегда, предлагает разработчикам сосредоточится на том, что делает их приложение уникальным — на самом бизнес-функционале, а инфраструктуру вокруг него использовать стандартную.
Api Management– это proxy, через которую мы можете определить типы подписок, тарификацию, настроить тротлинг/throtling, квоты/quotas, настроить списки доступа, вести модерацию пользователей Api, вести мониторинг использования. Т.е. вы со своего приложения снимаете то, что не определяет его бизнес-ценности для потребителя, и отдаете это на откуп Api Management. Где, на самом деле, хостится приложение при таком proxy — это не так важно для ваших клиентов (точка входа одна), а приложение можете и on Premise хостить, и в облаке.
Мне кажется, что это логическое продолжения концепции, которую Microsoft показала еще в Azure Data market.Ключевые концепции
Операция — вызываемый метод api. Тут все параметры, возвращаемые данные. В общем, то, что делает непосредственно действие. Конфигурация самого низкого уровня относится именно к операции. Api агрегирует набор операций (от 1 до N). Конфигурация и логическое объединение операций. Операции входят только в 1 Api. Продукт агрегирует набор api (от 1 до N). Сущность, которая предоставляется разработчикам, использующим Api, именно она тарифицируется. Пример: Допустим, у нас есть приложение, в котором можно переводить документы.Доменная модель: есть документ, у документа есть предложения их которых оно состоит, у предложения могут быть ревизии (версии перевода разными людьми, или в разное время).Концепции будем на ревизиях обсуждать.
Есть 2 операции: чтение всех ревизий сегмента и откат сегмента к какой-то ревизии.Эти 2 операции объединены в один api — Revisions.Само Revisions Api входит в продукт, в который, кроме него, входят еще Api работы с документами и самими сегментами. Но есть еще один продукт, в который это Revisions Api не входит, ибо клиенту оно не нужно, все переводится с первой попытки.
Мы можем из разного набора Api конфигурировать продукты, под конкретные пожелания потребителя.
Операции/Operations
Операция — это, фактически, метод api, который вызывается. Все его параметры настраиваются.В статье хорошо рассказано следующее: Как создать операцию, как установить http код ответа, как установить http глагол для операции, как создать список входных параметров, шаблон uri, пример текста ответа, установить тип возвращаемого контента, и если кэшировать, то сколько.
Api Создание api ничего сложного из себя не представляет- это uri + суффикс к нему (постфикс) и описание. После можно добавить в него операции, посмотреть список issues.Api можно не только создать вручную, но и импортировать/экспортировать форматах.Продукты/Products Продукт — это то, что получает его потребитель. На уровне продукта устанавливается лицензионное соглашение, на этом уровне устанавливается кто может пользоваться этим api, тарифный план, какие api в него входят, нужно ли получить approve, чтобы использовать api, или нет.Надо понять, что сам Api вне продукта никому не видим, а в продукте становится доступным только после публикации Api. Т.е. мы можем заранее создать продукты, но не публиковать их до поры до времени. Есть 2 интересные статьи как шаг за шагом настраивать продукты.
Группы/Groups Группа — это объединение пользовательских аккаунтов (windows live id, email.). Есть 3 предконфигурированные группы, но мы можем создать любое их количество.Созданную группу мы должны привязать к продукту, чтобы они могли что-то с этими api делать.Встроенныя группа администраторы — это те пользователи, которые могут менять настройки api. Developers — это встроенная группа пользователей, которые могут использовать Api. Guests — это не авторизованные пользователи. Им можно дать права на просмотр api, но не вызов. Так сказать, «смотреть, руками не трогать». Политики/Policies Я бы назвал их pre/post обработчики вызовов api, которые способны менять его поведение в зависимости от своих настроек.Сами политики могут быть привязаны как к продуктам, так и непосредственно к api или даже операциям. Это называется Policy Scope.Политики бывают входные и выходные. Сами они определяются в xml формате.Вот пример ограничения на IP:
Сейчас это жестко заданный набор потенциально возможных политик, полный список которых можно прочесть здесь.
Приведу список без описания:
Ограничительные
Квоты.
Лимиты
Ограничения на IP
Трансформации контента
Установить Http заголовки
Конвертировать из xml в json.
Заменить строку в теле сообщения
Установить/заменить параметр запроса.
Кэширование
Остальные
URI rewrite
Разрешить кросс доменные вызовы.
JSONP
CORS
Мониторинг/отчеты
Думаю, одним из самых интересных моментов будет система отчетности по используемым api. Кто, откуда, сколько раз запросил, как часто сервис не отвечал — это базовые вопросы, которые у всех возникают, и эта информация у вас будет из коробки.
Использование этой статистике на первом этапе будет большим подспорьем в развитии продукта, хотя в итоге скорее всего придется написать что-нибудь свое… Но до этого времени, вы с экономите кучу времени и денег, прежде чем писать свою систему.
Api Management Api Т.к. Api Management — это сервис, то у него тоже есть свой Api.Все, что можно сделать через portal, делается через тот же api, что имеет обычный разработчик. Поэтому Api даже особо описывать смысла нет — это просто работа с операциями, группами, продуктами. Включение, выключение, установка политик и так далее.Документация по Api доступна , SDK на nuget я не нашел, если честно, хотя думаю позже оно появится.
Кастомизация страницы api Любому api нужна страница с информацией о нем, желательно стилизованная и брендированная под компанию производителя. Одной страницей лучше не ограничиваться, а собрать небольшой сайт с примерами использования, контактами компании и прочей полезной информацией.В Api Management для этого представляется CMS (Orchard), с помощью которой можно и добавить страницы с контентом, и добавить и стилизовать сайт через css.
Естественно, мы должны понимать, что не все возможности стандартного Orchard можно использовать (написание своего кода на C#, например, невозможно), однако, как редактор контента, стилизация вполне выполняет свою задачу. Статья как это сделать.
Цены На данный момент вы можете выбрать 2 тарифных плана Т.к. сейчас этот сервис в preview, на него действует 50% скидка.Developer — Unit за 1.59$ в день, и за день можно отработать 166 тысяч запросов, 850 мб включенного в стоимость трафика. Standard — 11.26 в день и 6600 тысяч запросов с 35 включенными в цену гигабайтами данных на передачу. При превышении трафика по данным трафик тарифицируется стандартно, как и во всех остальных сервисах.P.S. Очевидная проблема, на мой взгляд, что если в вашем решении уже есть что-то по аналитике, мониторингу, то вам придется придумать, как связать это все вместе…Куда хуже, что вы полностью завязываетесь на платформу в плане авторизации.И еще хуже, если Вам придется одновременно предоставлять свое Api через Api Management и напрямую, т.к. это несколько точек настройки, где-то у Вас будет работать ограничение на число запросов, где-то нет… В общем, прежде чем брать этот сервис, стоит детально посмотреть, где функционал вашего решения пересекается с решением из Api Management и что делать, чтобы не дублироваться и не создать себе слоистую архитектуру.
Ссылки:
Если Вы хотите помочь улучшить статью- можно предлогать ваши правки через github.
