Чи слід писати бек-енд як API?

Сьогодні у мене була гостра дискусія щодо нашої програми MVC. У нас є веб-сайт, написаний на MVC ( ASP.NET ), і він, як правило, слідує шаблону зробити щось на виду -> натиснути на контролер -> контролер будує модель (викликає менеджера, який отримує дані, будує модель в сам метод контролера) -> модель переходить до перегляду -> промивання та повторення.

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

За його словами, рішення та найкраща практика - це створити API, а потім створити веб-сайт поверх свого API, а потім створити настільний додаток, мобільний додаток тощо дуже простий.

Мені це здається поганою ідеєю з різних причин.

У всякому разі, я, здається, не можу нічого знайти, гуглюючи, що могло б обговорити цю практику. Хтось має якусь інформацію про плюси, мінуси, навіщо це робити, чому не слід чи читати далі?

З деяких причин я вважаю це поганою ідеєю:

• Це занадто абстрактно, щоб запустити свій бекенд з API. Ви намагаєтесь зробити його занадто гнучким, що зробить це незмінним безладом.

• Усі речі, вбудовані в MVC, видаються марними, як ролі та автентифікація. Наприклад, атрибути та захист [Authorize]; вам доведеться згортати своє.

• Всі ваші дзвінки API вимагають додавання інформації про безпеку, і вам доведеться розробити токен-систему і багато чого іншого.

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

• Якщо мова йде про API, ви втрачаєте всілякі інструменти, такі як інтерфейси та абстрактні класи. Такі речі, як WCF, мають дуже напружену підтримку інтерфейсів.

• У вас є метод, який створює користувача або виконує якесь завдання. Якщо ви хочете створити 50 користувачів, ви можете просто зателефонувати йому 50 разів. Коли ви вирішите використовувати цей метод як API, ваш локальний веб-сервер може з назвою-pipe підключитися до нього, і це не має ніяких проблем - ваш клієнт настільного комп'ютера теж може його вдарити, але раптом ваше масове створення користувачів призведе до забивання API через Інтернет 50 разів, що не не добре Тож вам доведеться створити об'ємний метод, але насправді ви просто створюєте його для настільних клієнтів. Таким чином, у вас виникає необхідність: а) змінювати свій API на основі того, що з ним інтегрується, і ви не можете просто інтегруватися з ним, б) зробити набагато більше роботи, щоб створити додаткову функцію.

• ЯГНІ . Якщо ви спеціально не плануєте написати два однаково функціонуючі програми, одну веб-програму та одну програму для Windows, наприклад, це велика кількість додаткових робіт з розробки.

• Налагодження набагато складніше, коли ви не можете переступити до кінця.

• Багато незалежних операцій, для яких потрібно буде багато назад і назад, наприклад, якийсь код може отримати поточного користувача, перевірте, чи користувач перебуває в ролі адміністратора, отримайте компанію, до якої належить користувач, отримайте список інших учасників, надішліть їх усім E-mail. Для цього потрібно буде багато викликів API або написання методу "замовити" конкретне завдання, яке ви хочете, де єдиною перевагою цього способу буде швидкість, але зворотний бік буде нестійким.

• Можливо, ще кілька причин - це просто з моєї голови.

Мені це просто здається, якщо вам справді не потрібні два однакові програми, тоді це дійсно не варто. Я ніколи не бачив подібного додатку ASP.NET, вам доведеться написати два окремі додатки (API та ваш код) та керувати ними обома версіями (якщо на вашій сторінці користувача з’явиться нове поле, ви ' Вам доведеться одночасно оновлювати API та ваш споживчий код, щоб уникнути негативних наслідків або створити багато додаткової роботи для збереження його надійним).

Редагувати: Деякі чудові відповіді, починаючи добре розуміти, що це все означає зараз. Тож, щоб розширити питання, як би ви структурували додаток MVC для того, щоб слідкувати за цією структурою API?

Наприклад, у вас є веб-сайт, на якому відображається інформація про користувача. Під MVC у вас є:

Перегляд - (CS) HTML-сторінка, що відображає контролер UserViewModel - викликає GetUser () та створює UserViewModel, який передає класу диспетчерів перегляду (свого роду API), який має метод GetUser.

Контролер виконує GetUser (), але ви також хочете додаток для настільних ПК. Це означає, що ваш GetUser повинен бути виставлений через якийсь API. Вам може знадобитися TCP-з'єднання, або WCF, або, можливо, видалення. Ви також хочете мобільний додаток, який буде RESTful, оскільки стійкі з’єднання розмиті.

Тож ви б тоді написали API для кожного з них, веб-сервіс WCF, який має метод GetUser () і код просто так return new UserManager().GetUser()? І метод mvc 4 web api, який робить те саме? Продовжуєте дзвонити GetUser безпосередньо у вашому методі контролера MVC?

Або ви вибрали б рішення, яке працювало б для всіх трьох (послуга веб-api REST) ​​і будувати все на цьому, тому всі три програми здійснюють дзвінки API (mvc, на локальну машину).

І це просто теоретично досконалий сценарій? Я бачу великі накладні витрати в такому розвитку, особливо якщо вам доведеться розвиватися таким чином, що дозволить вам робити операції в RESTful способі. Я думаю, що дещо з цього було висвітлено у відповідях.

Редагувати 2: Прочитавши більше матеріалів, я поставив коментар нижче, що, думаю, може пояснити це. Питання - це трохи хитромудрий питання, я думаю. Якщо ви пишете свій бек-енд-інтерфейс в якості API, я збентежився, думаючи, що має існувати єдина веб-послуга, яка все (додаток mvc, настільний додаток, мобільний додаток) вимагає робити щось.

Я дійшов висновку, що те, що ви дійсно повинні зробити, це переконатися, що рівень вашої бізнес-логіки правильно відокремлений. Дивлячись на мій код, я це вже роблю - контролер зателефонує GetUser()на менеджера, а потім створить з нього модель перегляду для візуалізації з видом. Тож дійсно, рівень бізнес-логіки - це API. Якщо ви хочете зателефонувати на нього з настільного додатку, вам потрібно буде написати щось на зразок послуги WCF, щоб полегшити його виклик. Навіть просто використання методу WCF, GetUser()який містить код, return MyBusinessLayer.GetUser()було б достатньо. Таким чином, API - це бізнес-логіка, а WCF / web api тощо - це лише титри коду, які дозволяють зовнішнім програмам викликати його.

Таким чином, є деякий накладний випадок, у якому вам доведеться загортати рівень вашої бізнес-логіки в різні API, залежно від того, що вам потрібно, і вам доведеться написати метод API для кожної операції, яку ви хочете, щоб інші ваші додатки робили, плюс вам потрібно буде розібратися з способом аутентифікації, але здебільшого це те саме. Запишіть свою ділову логіку в окремий проект (бібліотека класів), і у вас, мабуть, не виникне жодних проблем!

Сподіваємось, це тлумачення правильне. Дякуємо за всі дискусії / коментарі, які вони викликали

Так, слід.

Це не тільки робить ваш задній край повторним для використання, але дозволяє забезпечити більшу безпеку та кращий дизайн. Якщо ви пишете свій бекенд як частину єдиної системи, ви створюєте монолітний дизайн, який ніколи не легко розширити, замінити чи вдосконалити.

Одне з напрямків, де це популярно на даний момент, - це мікросервіси . Там, де вихідний сервіс розділений на багато маленьких (або навіть великих) сервісів, які надають API, який спожиє клієнтська система. Якщо ви уявляєте, що у своїй програмі використовується багато сторонніх джерел даних, ви розумієте, що це вже робите.

Ще одна перевага полягає в тому, що побудову та обслуговування кожного сервісу можна передавати іншій команді, вони можуть додавати йому функції, які не впливають на будь-який інший продукт, який виробляє продукт. Тільки коли вони закінчені та відпустять свою послугу, ви почнете додавати у ваш продукт функції, щоб споживати їх. Це може зробити розвиток набагато більш плавним (хоча в цілому це може бути повільніше, ви прагнете покращити якість та зрозуміліше)

Редагувати: Добре. Я бачу вашу проблему. Ви думаєте про API як про віддалену бібліотеку. Це не. Подумайте про послугу як більше про послугу, що надає дані. Ви зателефонуєте до служби, щоб отримати дані, а потім виконати операції з цими даними на місцях. Щоб визначити, чи користувач увійшов у систему, ви зателефонували б " GetUser", а потім подивіться на 'logged on'значення, наприклад. ( Звичайно, YMMV з цим прикладом).

Ваш приклад для масового створення користувачів - це лише виправдання - тут немає різниці, все, що ви могли зробити в монолітній системі, все одно можна зробити в архітектурі сервісу (наприклад, ви б передали масив користувачів для масового створення, або створити єдиний. Ви все одно можете зробити точно так само з послугами).

MVC вже базується на концепції ізольованих послуг, лише рамки MVC об'єднують їх в єдиний проект. Це не означає, що ви втрачаєте що-небудь, крім комплектних помічників, які надає вам ваша рамка. Використовуйте іншу основу, і вам доведеться використовувати різні помічники. Або в цьому випадку прокатуйте свої власні (або додайте їх безпосередньо за допомогою бібліотеки).

Налагодження теж легко - ви можете ретельно перевірити API ізольовано, тому вам не потрібно буде налагоджувати його (і ви можете налагоджувати від кінця до кінця, Visual Studio може приєднуватися до декількох процесів одночасно).

Такі речі, як додаткова робота із впровадження безпеки, - це добре. Наразі, якщо ви з'єднаєте весь код на свій веб-сайт, якщо хакер отримує доступ до нього, вони також отримують доступ до всього, включаючи БД. Якщо ви розділите його на API, хакер може зробити дуже мало з вашим кодом, якщо вони також не зламають шар API - що буде для них надзвичайно складно (коли-небудь цікавилося, як зловмисники отримують величезні списки всіх користувачів веб-сайту або деталі комп'ютера? Це тому, що вони зламали ОС або веб-сервер, і він мав пряме з'єднання з БД, де вони могли select * from usersлегко працювати " ".

Я скажу, що я бачив багато веб-сайтів (і клієнт-серверних додатків), написаних так. Коли я працював у галузі фінансових послуг, ніхто б ніколи не писав веб-сайт «все-в-одному», почасти тому, що це занадто великий ризик для безпеки, а почасти тому, що велика розробка є досить графічним інтерфейсом через стабільну (тобто спадщину) обробку задніх даних систем. Розкрити систему DP як веб-сайт легко, використовуючи архітектуру стилю обслуговування.

2-е редагування: Деякі посилання на тему (для ОП):

Зауважте, що, коли про них говорять у контексті веб-сайту, веб-сервер слід вважати шаром презентації, оскільки саме клієнт викликає інші яруси, а також тому, що він конструює представлення інтерфейсу, що надсилаються в браузер для візуалізації. Це велика тема, і існує багато способів розробити додаток - орієнтований на дані або на домен (я зазвичай вважаю, що домен орієнтований "чистішим", але YMMV ), але все це зводиться до дотримання логічного рівня між ваш клієнт і ваша БД. Це трохи схоже на MVC, якщо ви вважаєте, що середина, API, рівень є еквівалентним вашій Моделі, лише модель не є простою обгорткою для БД, вона багатша і може зробити набагато більше (наприклад, сукупність даних з двох джерел даних, публікація -обробляти дані, щоб відповідати API, кешувати дані тощо):

• Багатоярусна архітектура
• Побудова додатка N-Tier в .NET
• Підручник Youtube - див. Також пов’язані посилання, у тому числі для впровадження в C #
• Навчальний курс з плюралізму (безкоштовна пробна версія або платний)

Ви не можете уникнути створення API . Навіть якщо ви створили "просто Веб-сайт", йому все одно доведеться якось отримувати свої дані з вашого сервера. Однак ви вирішили це зробити, це ваш фактичний API.

Знаючи це, справжнє питання полягає не в тому, чи створити API, а як його побудувати . Ви можете це робити на ходу як спеціальна річ - і дійсно, багато веб-сайтів побудовані саме таким чином - або ви можете ретельно розробити це таким чином, щоб воно було корисним в інших контекстах. Якщо вкластися в цей контекст, стає досить зрозуміло, що ваш колега має рацію: спочатку слід зробити API, а потім створити веб-сайт над ним.

Тим не менше, це, як ви зазначаєте, викликає певні проблеми. Щоб вирішити їх:

Це занадто абстрактно, щоб запустити свій бекенд з API. Ви намагаєтесь зробити його занадто гнучким, що зробить це некерованим безладом.

Це залежить від того, як ви це зробите. Як зазначає Джордж Поля у своєму відмінному тексті " Як вирішити це" , часто "більш загальну проблему може бути легше вирішити". Це називається Парадокс винахідника . Що стосується програмування, то це часто працює за допомогою розділення проблем: ваш бекенд більше не повинен стосуватися формату даних, які він вносить і виймає, і тому його код може бути набагато простішим. Вашим аналізаторам даних і рендерінгам більше не потрібно перейматися тим, що відбувається з даними, які вони створюють, тому вони теж можуть бути простішими. Все це працює, розбиваючи код на більш керовані фрагменти.

Усі речі, вбудовані в MVC, видаються марними, як ролі та автентифікація. Наприклад, атрибути та захист [Authorize]; вам доведеться згортати своє.

Зізнаюся, мені дуже важко співчувати людям, які відмовляються вивчати свої інструменти. Тільки тому, що ви не розумієте їх використання, це не означає, що вони марні, і це, звичайно, не означає, що ви повинні сковувати своє . Зовсім навпаки; вам не слід прокручувати власні інструменти, поки ви не зрозумієте альтернативи, щоб ви могли бути впевненими у вирішенні тих же проблем, що і у них (навіть якщо тільки по-своєму).

Розглянемо Лінуса Торвальда , який найвідоміший для написання Linux , але також написав git : зараз одна з найпопулярніших систем управління версіями у світі. Одним із рушійних факторів у його дизайні було глибоке протистояння Subversion (інший надзвичайно популярний VCS , і, мабуть, найпопулярніший на той момент git); він вирішив прийняти все, що могла Субверсія, і наскільки це було можливо, вирішити ці проблеми по-іншому. Для цього йому довелося самостійно стати експертом із Subversion саме для того, щоб він міг зрозуміти ті самі проблемні сфери та застосувати інший підхід.

Або в процесі вивчення ваших інструментів ви можете виявити, що вони корисні як є, і їх не потрібно замінювати.

Всі ваші дзвінки API вимагають додавання інформації про безпеку, і вам доведеться розробити токен-систему і багато чого іншого.

Так. Ось так і має бути.

Вам доведеться писати повні API-дзвінки для кожної функції, яку коли-небудь виконує ваша програма. Практично кожен метод, який ви хочете реалізувати, потребує використання API. Отримати / оновити / видалити для кожного користувача, плюс варіант для кожної іншої операції, наприклад оновити ім'я користувача, додати користувача до групи тощо тощо, і кожен з них буде виразним викликом API.

Не обов'язково. Тут грають такі архітектури, як REST . Ви ідентифікуєте ресурси, з якими працює ваша програма, і операції, які мають сенс застосувати до цих ресурсів, а потім впроваджуєте їх, не турбуючись про інших .

Якщо мова йде про API, ви втрачаєте всілякі інструменти, такі як інтерфейси та абстрактні класи. Такі речі, як WCF, мають дуже напружену підтримку інтерфейсів.

Навпаки, інтерфейси стають набагато важливішими, коли ви використовуєте API, не менше . Вони виходять у поданнях, до яких ви їх представляєте. Більшість людей в даний час визначають для цього формат на базі JSON , але ви можете використовувати будь-який бажаний формат, якщо ви добре його вказали. Ви виводите вихідні дані ваших дзвінків у цей формат на бекенді та розбираєте їх на все, що завгодно (можливо, той самий тип об’єкта) на фронталі. Накладні витрати невеликі, а приріст гнучкості величезний.

У вас є метод, який створює користувача або виконує якесь завдання. Якщо ви хочете створити 50 користувачів, ви можете просто зателефонувати йому 50 разів. Коли ви вирішите використовувати цей метод як API, ваш локальний веб-сервер може з назвою-pipe підключитися до нього, і це не має ніяких проблем - ваш клієнт настільного комп'ютера теж може його вдарити, але раптом ваше масове створення користувачів призведе до забивання API через Інтернет 50 разів, що не не добре Тож вам доведеться створити об'ємний метод, але насправді ви просто створюєте його для настільних клієнтів. Таким чином, у вас виникає необхідність: а) змінювати свій API на основі того, що з ним інтегрується, і ви не можете просто інтегруватися з ним, б) зробити набагато більше роботи, щоб створити додаткову функцію.

Створення об'ємної версії існуючого методу навряд чи те, що я б назвав "набагато більше роботи". Якщо вас не турбують такі речі, як атомність, об'ємний метод може виявитися не набагато більше, ніж дуже тонкий фронт для оригіналу.

ЯГНІ . Якщо ви спеціально не плануєте написати два однаково функціонуючі програми, одну веб-програму та одну програму для Windows, наприклад, це велика кількість додаткових робіт з розробки.

Ні, YANI (Ви вже це потребуєте). Я окреслив це як вище. Питання лише в тому, скільки дизайнерських робіт вкласти в нього.

Налагодження набагато складніше, коли ви не можете переступити до кінця.

Чому б вам не вдалося перейти до кінця?

Але більш суттєвим є те, що можливість аналізувати дані, що рухаються вперед та назад, у легко розпізнаваному форматі, який вирізає всю сукупність дисплея, насправді прагне зробити налагодження простішим , а не складніше.

Багато незалежних операцій, для яких потрібно буде багато назад і назад, наприклад, якийсь код може отримати поточного користувача, перевірте, чи користувач перебуває в ролі адміністратора, отримайте компанію, до якої належить користувач, отримайте список інших учасників, надішліть їх усім E-mail. Для цього потрібно буде багато викликів API або написання методу "замовити" конкретне завдання, яке ви хочете, де єдиною перевагою цього способу буде швидкість, але зворотний бік буде нестійким.

REST вирішує це, працюючи над повними об'єктами ( ресурсами , щоб використовувати терміни теорії REST), а не окремими властивостями об'єктів . Щоб оновити ім'я користувача, ви отримаєте об’єкт користувача, зміните його ім’я та поверніть його назад. Ви можете вносити інші зміни одночасно із зміною імені користувача. Більш загальну проблему стає легше вирішити, оскільки ви можете усунути всі ті індивідуальні виклики для оновлення окремих властивостей об'єкта: ви просто завантажите його і збережіть.

У чомусь це не відрізняється від архітектури RISC на апаратній стороні. Однією з ключових відмінностей між RISC та CISC (його попередником) є те, що архітектури CISC, як правило, включають багато інструкцій, які працюють безпосередньо на пам'яті, тоді як архітектури RISC, як правило, функціонують в основному в регістрах: в чисто архітектурі RISC єдиними операціями з пам'яттю є ЗАВАНТАЖУЙТЕ (скопіюйте щось із пам'яті в реєстр) та ЗБЕРЕГНУЙТЕ (візьміть значення з регістра та вставте його в пам'ять).

Ви б могли подумати, що це означатиме провести набагато більше поїздок від регістрів до пам'яті, що сповільнить роботу машини. Але на практиці часто відбувається навпаки: процесор (клієнт) робить більше роботи між поїздками в пам'ять (сервер) , і ось звідки відбувається прискорення.

Коротка історія: ваш колега правий. Це шлях. В обмін на трохи попередню роботу, це значно спростить код вашого веб-сайту та дасть змогу краще інтегруватися з іншими веб-сайтами та додатками. Це ціна, яку варто заплатити.

Подальше читання:

1. REST API Design - Моделювання ресурсів

Я знаю, що мікросервіси зараз лютують, але вони не завжди того варті. Так, мета є нещільно пов'язаним кодом. Але це не повинно йти за рахунок більш болісного циклу розвитку.

Хорошим середнім фактором було б створити окремий проект даних у своєму рішенні. Проект даних буде бібліотекою класів .NET. Ваш проект ASP.NET MVC додасть посилання на бібліотеку даних, і всі моделі будуть виведені з проекту даних. Тоді, коли прийшов час створити настільний або мобільний додаток, ви можете посилатися на той самий код. Тож це може бути не офіційний API, але він буде функціонувати як єдиний. Якщо ви хочете зробити це доступним як API, ви можете створити простий веб-проект, який виконує функції обгортки для проекту даних.

Microsoft просуває цю концепцію, яку вони називають бібліотеками портативних класів .

Ні, не слід . Якщо у вас немає негайних планів створити альтернативні фронтальні програми (наприклад, програми для мобільних пристроїв або настільних ПК або окремі веб-програми), які отримують доступ до того ж сервера, тоді вам не слід вводити рівень веб-сервісу. ЯГНІ .

Вільне з'єднання завжди бажано (поряд з високою згуртованістю), але це принцип дизайну і не означає, що вам доведеться фізично розділяти об'єкти на різних серверах! І неправильно розроблений API сервісу може створювати щільне з'єднання через межі сервера, тому наявність API не гарантує вільної зв'язку.

Якщо в майбутньому виникає потреба в API сервісу, ви завжди можете його ввести в цей момент. Поки ви будете тримати свій код добре шаруватим (доступ до даних та логіка бізнесу чітко відокремлені від логіки інтерфейсу користувача), ввести це буде не важче пізніше, ніж зараз. І отримана конструкція буде набагато кращою, якщо розроблена відповідно до фактичних вимог.

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

Моя компанія має такий додаток, побудований таким чином. Спочатку нам було доручено створити задній з API для переднього кінця, який створював інший розробник. Коли інший розробник не зміг розробити цей передній кінець, нам було доручено побудувати і передню частину. Хоча в цьому підході безумовно є переваги, є величезний недолік: вартість. Початкова збірка буде значно дорожчою, а постійне технічне обслуговування буде дорожче, завдяки більшому коду для обслуговування та тому, що дві окремі системи теж розгорнуті. Завдяки додатковим витратам, це завжди має бути діловим рішенням, а не приймати примх розробників.

Якщо говорити про це, я б оцінив, що проект, про який я згадував, коштував на 20% більше завдяки такому підходу. Ви не описуєте, над яким типом проекту ви працюєте над тим, в якій компанії ви працюєте, але якщо ви починаєте будувати їхній продукт, то додаткові витрати можуть бути різницею між доставкою кількох додаткових функцій, які роблять ваш продукт успіх.

Ще одна причина, принаймні не універсальна, полягає в тому, що якщо або коли ви вирішите створити цей другий інтерфейс, рідко зустрічається відображення функціональності. Якщо ви робите мобільний додаток, наприклад, вони мають менше функцій. Це означає, що деякі ваші методи API ніколи не будуть використані повторно. Тому компромісом з колегою може бути вирішення між вами найважливіших / найважливіших викликів та додавання їх до API, а також використання більш традиційних методів для всього іншого.

Ще один момент, який слід врахувати, - це те, що ваш колега каже, що ви не зможете повторно використовувати свій існуючий код, що не відповідає дійсності, якщо ви розділите свою бізнес-логіку. Вам просто потрібно створити тонку обгортку веб-служб навколо внутрішніх API, що не є особливо великим завданням. Було б наївно думати, що ви все-таки зможете повторно використовувати рівень веб-сервісу для іншого переднього кінця, без змін.

Це залежить від типу програми та типу ринку, на якому ви перебуваєте.

Існують компроміси та переваги, якщо йти цим шляхом. Це не однозначна відповідь, що один спосіб кращий за інший.

Я поговорю з особистого досвіду. Я був тим, хто вирішив взяти кодову базу, над якою працюю в цьому напрямку ще в 2007 році. Ця база коду зараз десь близько мільйона рядків коду, половина з яких - код сервера, прихований за величезною кількістю веб-сервісу API, інша половина - це флотилія клієнтів, настільний робочий стіл, веб-настільний ПК, мобільний, бек-енд інтеграції тощо ... Це рішення не обійшлося без його недоліків, але з огляду 20/20 я можу сказати, що зробив би це ще раз . Дозвольте вказати на деякі компроміси.

Переваги

• Гнучкість. Незалежно від того, чи є це запит на створення мобільного додатка для збільшення досвіду на робочому столі або про інтеграцію із задньою частиною SAP, все стає простіше, коли ви вже маєте API для виклику. Коли ви отримаєте достатньо цих запитів, ви органічно розвинетесь до API, і питання лише в тому, чи є у нього стандартний веб-сервіс перед ним, чи це внутрішній API, де веб-сервіси зроблені з урахуванням потреби.

• Масштабованість (команди). У нашому випадку у нас є багато різних груп розробників, які працюють над цим API. У нас навіть є спеціалізовані команди API, які розмовляють з різними групами, підсумовують потреби та будують з нього цільовий API. Дійшло до того, що нам навіть навіть не кажуть, що люди будують речі на основі API, і не всі, хто це робить, працюють для нашої компанії.

• Безпека. Чіткий розподіл між небезпечною та безпечною частинами вашої кодової бази корисний для міркування безпеки. Змішування інтерфейсу користувача та коду, що складається з резервного коду, має тенденцію плутати справи.

Компроміси

• Гнучкість. Ви повинні виконати роботу, щоб "правильно" вбудувати щось в API. Неможливо швидко запустити запит БД з коду інтерфейсу для вирішення конкретної проблеми. Крім того, API, які фактично використовуються повторно, повинні враховувати стільки випадків використання, що швидке рішення, як правило, є неправильним рішенням. API стає менш гнучким для еволюціонування, тим більше, що там так багато клієнтського коду (ми переходимо до версії API з цієї причини).

• Початкова швидкість розвитку. Розробляти API спочатку повільніше, без клаптиків сумнівів. Ви повернете це лише тоді, коли у вас буде достатньо клієнтів, створених на основі API. Але тоді ви виявите, що вам потрібні 3 різні клієнтські реалізації, перш ніж ваш API розвинеться, щоб бути достатньо загальним. Ми виявили, що більшість наших початкових дизайнів API були неправильними, і нам довелося сильно переглянути наші вказівки щодо створення веб-служб.

Червоні оселедці

Ви згадали про купу таких. Вони насправді не мають значення на практиці.

• Абстракція. Ваш API стає досить абстрактним, щоб охопити всі випадки використання, які потрібно обслуговувати вашим продуктом, і не більше того. Навіть без веб-сервісів у вас буде або внутрішній API, який робить це, або мати багато дублікатів коду. Я віддаю перевагу абстракції над дублюванням.

• Відмова від стеку MVC на стороні сервера. У ці дні майже кожній системі через деякий час знадобиться мобільний додаток. Після цього ви будуєте веб-сервіси для задоволення цього мобільного додатка, вам доведеться розібратися, як зробити аутентифікацію та авторизацію в контексті API. Насправді менше роботи, коли у вас є лише один спосіб зробити це, як ви це робите у своїх веб-службах.

• Масові операції. Зазвичай вирішується шляхом створення об'ємного API, який запускає бек-енд завдання і повертає ідентифікатор завдання для запиту стану. Це не така велика угода.

• Налагодження. Я виявив, що загалом виправити систему стало трохи простіше. Ви все ще можете встановити точки перерви як в передньому, так і в зворотному коді, тому на практиці не так важко переступити, і ви отримаєте можливість будувати автоматизовані тести api та інструментувати api для моніторингу виробничих систем.

• Багато незалежних операцій. Це питання про те, як ви проектуєте речі. Якщо ви наполягаєте на наявності чистого API CRUD, то так, ви будете страждати від цього питання. Але, маючи деякі API CQRS для розширення, що зазвичай є хорошою ідеєю, і якщо ви переконалися, що у вас є внутрішній API, для якого служби є передовим, ви можете легко використовувати цей внутрішній API для побудови служб для цих конкретних сценарій.

Підсумки

У системі, що використовується в достатній кількості різних контекстів, API природно розвиватиметься, оскільки це найпростіший спосіб задовольнити всі потреби. Але напевно є випадок YAGNI. Є компроміси, і це не має сенсу, поки це не має сенсу. Ключовим моментом є не бути догматичним і не розкривати розум до різних підходів в архітектурі для задоволення змін, що розвиваються.

Те, що розповідає ваш колега, - це архітектура, орієнтована на сервіс. Це може бути надзвичайно масштабованим, перевіреним та розумним способом кодування, але це дійсно залежить від того, що ви робите.

Є кілька вагомих переваг SOA, які я спробую перерахувати:

Масштабованість

Оскільки ваш задній кінець роз'єднаний, ваш передній кінець стає лише серією шаблонів, навіть плоских. Плоскі файли надзвичайно швидкі та дешеві для обслуговування з будь-якого CDN. Вони можуть бути мінімізовані та попередньо скомпільовані у статичний HTML, а потім заповнені клієнтами даних.

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

Заповітність

MVC зазвичай починається чистим, але на практиці контролери рідко залишаються зосередженими на одному ресурсі. Чим більше речей у ваших методах контролера, тим менш випробуваними вони стають.

API вирішує цю проблему. Кожен дзвінок API витягує ресурс і обслуговує його. Чисте і тестоване.

Гарантоване розділення проблем

Ваш передній і задній кінці повністю розлучені. Ви можете надати передню частину іншому розробнику або дизайнеру. Це MVC виведено на інший рівень. Я впевнений, що ви не хочете відмовлятися від MVC. SOA - це MVC, але більше.

Недоліки

Звичайно, є і деякі недоліки. Моноліт часто швидше розпочати. Це може бути те, до чого ти звик. Це може красивіше вписатись у вашу групу. Ваші інструменти можуть бути оптимізовані для створення моноліту.

На мою думку, жодне з цих особливо не є вагомими причинами, і ви можете подумати про переобладнання, якщо вони стосуються вас.

Тут є багато хороших відповідей, тому я просто додам досвід своєї реалізації.

Ось як я роблю речі:

• Створіть рівень доступу до бази даних, який обробляє взаємодію з усіма / лише БД (зазвичай вручну використовується SQL для швидкості та керування, немає ORM) . Вставити, оновити, видалити, вибрати ...
• Створіть interface( virtual class), що розкриває / виконує потрібні мені функції API. Коли вони будуть реалізовані, вони використовуватимуть високоспеціалізовані функції DBAL для досягнення результатів. Це також допомагає мені застосувати API на рівні компілятора, тому я переконуюсь, що в програмі Server + API є всі вбудовані функції.
• Створіть Другий рівень, який реалізує інтерфейс (це власне API) та застосовує обмеження безпеки. Ви також тут взаємодієте із зовнішніми API.
• Веб-сайт використовує Другий рівень безпосередньо (для продуктивності), не переходячи через API, доступний для віддаленого доступу (наприклад, SOAP, JSON) .
• Автономний сервер - це побудова, яка реалізує інтерфейс і виставляє Другий рівень як фактичний віддалений доступ API для зовнішніх настільних / мобільних клієнтів (доступ не для веб-сайтів) . Все, що він робить - це декодування запитів та кодування відповідей та управління / відключення клієнтів. Він також підтримує можливості віддачі для масового сповіщення клієнтів про події, згенеровані іншими підключеними колегами (функціональність, яку веб-сайт зазвичай не вимагає) .

Отже, технічно API - це другий рівень. Ви користуєтесь ним безпосередньо на веб-сайті та виставляєте його віддаленим клієнтам через сервер. Код повторно використовується, і жоден шматок коду для багаторазового використання ніколи не є вбудованим. (жити і вмирати за цим правилом, і все приголомшливо) Допомагає у ремонті, тестуванні ... усього.

Ви ніколи не підключаєте веб-сайт до настільного / мобільного сервера API (якщо ваш сайт не AJAX та працює на JSON) . Але якщо на сайті розміщено динамічний вміст у розмітці, проходження проміжного API дозволить зняти вашу ефективність. Веб-сайт повинен бути швидким! Віддалений доступ клієнта може бути трохи більш повільним.

PS : Так, обслуговування трохи складніше, оскільки більшість коліс працюють разом, але це простіше в довгостроковій перспективі. Тож якщо ваш проект покликаний жити деякий час і є трохи складним, завжди майте API. Також набагато простіше протестувати кожен шар самостійно.

Суть суперечки не в тому, якщо ви повинні використовувати API, а в тому, що насправді є "API". Єдиною альтернативою для використання розробленого API є використання API, який є випадковим безладом коду. Ви пишете, що API робить речі "занадто гнучкими", що, в свою чергу, робить речі некерованими. Це вказує на повне і глибоке нерозуміння того, що таке API. Якщо це непорозуміння не ділиться між вами та вашим колегою, то ви витратили багато часу, сперечаючись над зовсім іншими речами.

Не використовуючи чітко визначений API, ви можете робити все, що завгодно. За визначенням це найбільш гнучкий варіант. Крім того, за визначенням "роби все, що хочеш", це все ще API. Тільки робота з API, щоб видалити гнучкість. Знімаючи гнучкість, хороший API спонукає користувача робити подібні речі подібними способами.

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

Приклад

• Безліч незалежних операцій, за якими потрібно багато назад і назад, наприклад, якийсь код може отримати поточного користувача, перевірте, чи користувач перебуває в ролі адміністратора, знайдіть компанію, до якої належить користувач, отримайте список інших учасників, надішліть їх весь електронний лист. Для цього потрібно буде багато викликів API або написання методу "замовити" конкретне завдання, яке ви хочете, де єдиною перевагою цього способу буде швидкість, але зворотний бік буде нестійким.

Кількість викликів API, які потребують цього пристойного API, ймовірно, буде 1. Так, це негнучко, але чому б ви хотіли, щоб він був гнучким?

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

Ну, чи не так? Якщо ні, то це досить неактуальне твердження.

Я б сказав, якщо ви збиралися створити нову програму в 2015 році, тоді серйозно вивчіть щось із користувальницьким інтерфейсом, що включає API, а не HTML-сторінки, створені сервером. Є чіткі витрати, але і чіткі переваги.

Але якщо у вас є існуючий сайт без будь - яких конкретних планів , щоб мати декілька різних інтерфейсів (наскільки я можу сказати), то його коментарі просто недоречні.

Коротка версія: Ваш контролер ефективно API, незалежно від того; хоча ASP.NET це затьмарює.

Більш довга версія:

Подумайте про базовий веб-додаток MVC, який надає інформацію про пиво та необов'язково продає вам його. Як виглядають маршрути?

/sign_in
/sign_out
/beer
/beer/{beer_name}
/order
/order/{order_number}

У звичайному веб-додатку, ймовірно, є кілька допоміжних маршрутів, таких як:

/beer/new
/beer/{beer_name}/edit
/beer/{beer_name}/delete
/order/new
/order/{order_number}/edit
/order/{order_number}/delete

У веб-API це не потрібно, оскільки вони випливають із методу HTTP.

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

Після деякого копання я визначив, що це може бути стан речей для вас, залежно від версії ASP.NET, яку ви використовуєте. Старіший MVC 5 і раніше не вистачає конвенцій та інтерфейсу для надійної уніфікації двох реалізацій. У старих версіях веб-додатки, що повертаються, заповнює перегляд, тоді як API дає HttpResponse. У будь-якому випадку, однак, вони генерують ту саму відповідь семантично.

Якщо ви використовуєте MVC 6, ви отримуєте обидва в уніфікованому класі контролерів, які можуть бути розумними щодо того, що він повертає. Я не знайшов жодного хорошого прикладу коду ASP для цієї моделі, але знайшов код Rails з тією ж схемою. Розглянемо цей контролер як "лайки" від проекту "Діаспора" . Кожен метод управління має маршрути , визначені в «винахідливою конвенції» тут цю суму до LCRUD як API.

Однак, якщо ви читаєте реалізацію, кожен може відповісти на HTML, мобільний HTML або JSON. Це в поєднанні з умовою пошуку переглядів повністю уніфікує веб-додаток та веб-API. Ви також зауважите, що не всі методи насправді надають кожну відповідь (що має сенс, оскільки інтерфейс може вимагати методів, яких API не буде, і навпаки).

Це невідповідність імпедансу, оскільки ASP.NET начебто все це вигадав із запізненням, тоді як Рейки вже деякий час сприймає симетрію та робить це зрозумілим.

Спекуляція:

Ваш колега, мабуть, і правильний, і неправильний, залежно від того, яку версію ASP ви використовуєте. Згідно зі старою версією MVC, різниця між API та додатком, ймовірно, зробила це "найкращою практикою" для створення API вперед, тому що модель ASP.NET насправді не дозволяла добре використовувати код там.

У новій версії має сенс використовувати уніфікований код, оскільки полегшити повторне використання коду з базовим класом уніфікованого контролера.

У будь-якому випадку, Контролер фактично є API.

Коли я розпочав свою кар'єру в 2006 році, цей тип архітектури був дуже лютим у світі .NET. Я працював над 3-ма окремими проектами, розробленими в середині 2000-х, з веб-сервісом між рівнем бізнес-логіки та веб-інтернетом. Звичайно, в наші дні веб-сервіси були SOAP, але це все одно та ж архітектура. Передбачуваними перевагами була можливість перемикання або переднього, або бекенда і навіть розробляти настільну програму. Зрештою, YAGNI виявився правдою. Я ніколи не бачив, щоб щось із цього сталося. Весь цей час я бачив лише вартість поділу проекту таким чином. Я навіть закінчив виривати веб-сервіс із одного з проектів (пішло півроку, щоб видалити його крок за кроком, роблячи інші речі), і вся команда була задоволена. Я ніколи не пробував такого підходу, і не буду, якщо мені не дадуть дуже конкретні причини. 5-річний досвід роботи з цією архітектурою навчив мене, що мені це не потрібно, і жодна кількість експертів, які говорять мені про зворотне, не переконує мене в цьому. Це може зробити лише проект, де мені це потрібно.

Тепер, коли це сказано, я дуже намагаюся створити прошарок між бізнес-логікою та контролерами / презентаторами. Наприклад, у мене є рівень обслуговування, я ніколи не виставляю довідників, використовую інтерфейси для всіх моїх служб і вводять їх у контролери з IoC. Якщо мені коли-небудь потрібна веб-служба в моїй архітектурі, я зможу представити її з розумною вартістю. Я просто не хочу платити цю вартість заздалегідь.

Також мені дуже подобається ідея мікросервісів, але я розумію, що мікросервіс означає вертикальні модулі, а не горизонтальні шари. Наприклад, якщо ви будуєте facebook, функція чату буде окремою службою, розгорнутою окремо на власних серверах тощо. Я б заохочував цей тип незалежних служб.

Треті сторони будуть ним користуватися? Так, слід .

Ви плануєте повторно використовувати його в не так далекому майбутньому? Так, слід.
Ви будете третьою стороною , маючи задокументований - або документований - або придатний для використання стороннім API інтерфейс, забезпечить вам міцну можливість повторного використання та модульність.

Ви поспішаєте? Ні, не слід.
Після цього рефакторинг простіший та швидший, ніж прогнозує та розповідає більшість методик та викладачів. Важливіше мати щось, що працює (навіть із поганим внутрішнім дизайном, як це можна і буде відновлено), ніж мати взагалі нічого. (але з неймовірним внутрішнім дизайном, wohoo)

Передня частина може ніколи не побачити світло дня через причини? Так, слід .
Я додав цю причину тому, що, ну, це зі мною трапилось багато.
І принаймні мені залишаються свої компоненти для повторного використання та перерозподілу тощо.

Тут є хороші відповіді. Я публікую це як часткову відповідь; можливо, це було б краще, як коментар. Однак дотримуватися того ж коментаря до численних дописів - це не добре.

Не можна стверджувати, що YAGNI є причиною не створення API.

API - це природна та логічна кінцева точка тестування. Таким чином, прямо з 0 дня, є два додатки, які використовують API: інтерфейс користувача та набір тестування. Один призначений для людей, інший призначений для машин. Вони обов'язково різні. Тестування поведінки на передньому рівні - це набагато інше завдання, ніж тестування поведінки на передньому рівні. Таким чином, техніка, і, можливо, інструменти, абсолютно різні. API дозволяє використовувати найкращий інструмент для роботи. Крім того, з відокремленням, що надається API, передній тестери не повинні перевіряти функціональність.

API також допомагає утримувати передні кодери від проблем, що стосуються кодера, і навпаки. Це дуже різні навички в нашій компанії; API дозволяє нам зосередитись там, де ми найсильніші.