Послуга API MVC та RESTful

MVC досить простий. Є Модель, Контролер та Вид. Коли ми створюємо веб-сайт, це все поєднується, коли « клієнт надсилає на сервер запит ключового слова REST -> сервер відповідає запитуваній URL-адресі дії контролера -> який потім викликає моделі (и) для збору / обробки даних, отримує результат -> і повертає результат назад клієнту як HTML-сторінку (перегляд) '.

Що робити, якщо ми говоримо про чистий веб-сервіс API RESTful? Тоді потік з "чимось на кшталт" клієнт надсилає запит на ключове слово REST на сервер -> сервер відповідає запитуваній URL-адресі до дії контролера -> який потім викликає моделі (і) для збору / обробки даних, отримує результат -> і повертається результат повертається до клієнта в JSON '. Те саме, що і раніше, але немає «виду» ... точніше, створений JSON можна розглядати як «вид». У певному сенсі ми використовуємо лише MC частину MVC. Це так треба робити? Або є якісь інші, більш підходящі шаблони для служби лише для API, а не MVC?

MVC - парадигма світу Smalltalk, що стосується того, як об’єктно-орієнтовані системи можуть мати інтерфейси користувача.

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

Вся справа в тому, що оригінальний MVC зі світу Smalltalk насправді не є тим, що MVC є у більшості веб-рамок. Виведення HTML насправді не є "переглядом" в тому сенсі, що Smalltalk розумів, що це екран із інтерфейсом користувача.

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

По-друге, MVC - це лише спосіб структурування коду сторони сервера. Це дійсно не має нічого спільного з REST / HTTP. REST стосується того, як спілкуються клієнти та сервери. Не байдуже, чи представлення, яке сервер надсилає клієнтові, знаходиться в HTML-шаблоні, який знадобився багато для побудови за допомогою шаблону двигуна, або об'єкту JSON, який був одним викликом у контролері.

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

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

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

MVC досить простий.

Мартін Фаулер, можливо, не погодиться з цим :

Різні люди, які читають про MVC в різних місцях, приймають різні ідеї і описують їх як "MVC".

Жити далі...

Коли ми створюємо веб-сайт, це все поєднується, коли «клієнт надсилає на сервер запит ключового слова REST -> сервер відповідає запитуваній URL-адресі до дії контролера -> який потім викликає моделі (і) для збору / обробки даних, отримує результат -> і повертає результат назад клієнту як HTML-сторінку (перегляд) '.

Гаразд, це трохи клубок

MVC, що б це не було, це сукупність ідей для реалізації користувальницьких інтерфейсів.

REST - це сукупність архітектурних обмежень для розробки масштабних додатків.

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

Подібність, яку ви бачите між двома, (візьміть свій вибір) неправильно віднесена або поверхня.

RESTafarians мають загальне розуміння HATEOAS , "гіпертексту як двигуна стану програми", і це повинно надсилати тривогу, що дзвонить вам через голову - чому б погляд був двигуном стану ? Якщо ми поставимо під сумнів передумови та шукаємо додаткові докази, ми можемо також помітити дві дивні речі.

По-перше, ми можемо повністю вивести HTTP-сервер із рівняння, завантаживши HTML з диска. Браузер прекрасно задоволений цим, виправдовуючи деякі незначні зміни в поведінці, які можуть виникнути внаслідок зміни базового URL-адреси. Перегляди зазвичай не продовжують працювати, коли вони повністю відключені від моделі та контролера.

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

Відповідь на загадку, звичайно, полягає в тому, що HTML не є переглядом. Колекція віджетів у веб-переглядачі - це перегляд, і вони взаємодіють із Модель об'єкта документа , яка була ініціалізована зчитуванням HTML.

Іншими словами, HTML - це представлення держави, як і обіцяв Рой Т. Філдінг .

Що робити, якщо ми говоримо про чистий веб-сервіс API RESTful ...? Те саме, що і раніше, але "перегляду" немає

Правильніше, те саме, що і раніше: немає виду. JSON, як і HTML, є поданням стану, придатного для перетину меж процесу.

Подумайте, що "DTO" або "Message", і висновки будуть набагато рідше зірвати вас.

Це так треба робити?

Передача JSON у вигляді подання або використання його як моделі перегляду для побудови подання не порушує шаблон.

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

Або є якісь інші, більш підходящі шаблони для служби лише для API, а не MVC?

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