MVC и RESTful API сервис

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, который был одним вызовом в контроллере.

Если вы не думаете, что вашему серверу нужен слой «view», это нормально. Вы все равно получите выгоду, отделяя свою бизнес-логику (то есть модель) от контроллеров, которые обрабатывают определенный 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» или «Сообщение», и вы сделаете выводы, что с гораздо меньшей вероятностью приведет вас в заблуждение.

Так ли это должно быть сделано?

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

Я использую ту же архитектуру в текущем приложении, над которым я работаю, и это работает очень хорошо. Вместе с некоторыми хорошими JS-фреймворками вы можете создавать действительно адаптивные проекты.

Или есть другие, более подходящие шаблоны для службы только API вместо MVC?

Честно говоря, не знаю. Но я думаю, что не важно, используете ли вы MVC или нет в API. Используйте то, что вы считаете удобным. Говоря о веб-сервисах, необходимо учитывать гораздо более важные аспекты (которые не имеют прямого отношения к MVC), например, безопасность, согласованность, доступность и т. Д.