Azure Api Management

    Вже досить давно в Microsoft Azure в preview знаходиться сервіс Api Management. На Хабре його анонсували в травні.
 
 

Ідея

Microsoft, як завжди, пропонує розробникам зосередиться на тому, що робить їх додаток унікальним — на самому бізнес-функціоналі, а інфраструктуру навколо нього використовувати стандартну.
 image
 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, приклад тексту відповіді, встановити тип повертається контенту, і якщо кешувати, то скільки.
 image
 image
 image
 image
 image
 
 

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
 
 image
 
Зараз це жорстко заданий набір потенційно можливих політик, повний список яких можна прочитати тут .
Наведу список без опису:
 
     
  • Обмежувальні
       
    • Квоти.
    •  
    • Ліміти

    •  
    • Обмеження на IP
    •  
      
  •  
  • Трансформації контенту
       
    • Встановити Http заголовки
    •  
    • Конвертувати з xml в json.

    •  
    • Замінити рядок в тілі повідомлення
    •  
    • Встановити / замінити параметр запиту.
    •  
      
  •  
  • Кешування
  •  
  • Решта
       
    • URI rewrite
    •  
    • Дозволити крос доменні виклики.

    •  
    • JSONP
    •  
    • CORS
    •  
  •  
 
 

Моніторинг / звіти

Думаю, одним з найцікавіших моментів буде система звітності по використовуваних api. Хто, звідки, скільки разів запросив, як часто сервіс не відповідав — це базові питання, які у всіх виникають, і ця інформація у вас буде з коробки.
 image
 image
Використання цієї статистиці на першому етапі буде великою підмогою в розвитку продукту, хоча в підсумку швидше за все доведеться написати що-небудь своє… Але до цього часу, ви з економите купу часу і грошей, перш ніж писати свою систему.
 
 

Api Management Api

Т.к. Api Management — це сервіс, то у нього теж є свій Api.
Все, що можна зробити через portal, робиться через той же api, що має звичайний розробник. Тому Api навіть особливо описувати сенсу немає — це просто робота з операціями, групами, продуктами. Включення, виключення, установка політик і так далі.
Документація по Api доступна , SDK на nuget я не знайшов, якщо чесно, хоча думаю пізніше воно з'явиться.
 
 

Кастомізація сторінки api

Будь-якому api потрібна сторінка з інформацією про нього, бажано стилізована і брендована під компанію виробника. Однією сторінкою краще не обмежуватися, а зібрати невеликий сайт з прикладами використання, контактами компанії та іншої корисною інформацією.
В Api Management для цього представляється CMS (Orchard), за допомогою якої можна і додати сторінки з контентом, і додати і стилізувати сайт через css.
Природно, ми повинні розуміти, що не всі можливості стандартного Orchard можна використовувати (написання свого коду на C #, наприклад, неможливо), однак, як редактор контенту, стилізація цілком виконує свою задачу. Стаття як це зробити.
 
 

Ціни

На даний момент ви можете вибрати 2 тарифних плану Т.к. зараз цей сервіс в preview, на нього діє 50% знижка.
 
     
  1. Developer — Unit за 1.59 $ в день, і за день можна відпрацювати 166тисяч запитів, 850Мб включеного у вартість трафіку.
  2.  
  3. Standard — 11.26 в день і 6600тисяч запитів з 35 включеними в ціну гігабайтами даних на передачу.
  4.  
При перевищенні трафіку за даними трафік тарифікується стандартно , як і у всіх інших сервісах.
 
 P.S.
Очевидна проблема, на мій погляд, що якщо у вашому рішенні вже є щось по аналітиці, моніторингу, то вам доведеться придумати, як пов'язати це все разом…
Куди гірше, що ви повністю зав'язувалися на платформу в плані авторизації.
І ще гірше, якщо Вам доведеться одночасно надавати своє Api через Api Management і безпосередньо, т.к. це кілька точок настройки, десь у Вас буде працювати обмеження на число запитів, десь ні… Загалом, перш ніж брати цей сервіс, варто детально подивитися, де функціонал вашого рішення перетинається з рішенням з Api Management і що робити, щоб не дублювати і не створити собі шарувату архітектуру.
 
Посилання
  
Якщо Ви хочете допомогти поліпшити статью- можна предлогать ваші правки через github
    
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.