MVC довольно прост. Есть Модель, Контроллер и Вид. Когда мы создаем веб-сайт, все это объединяется, когда клиент отправляет запрос ключевого слова REST на сервер -> сервер сопоставляет запрошенный URL с действием контроллера -> который затем вызывает модель (ы) для сбора / обработки данных, получает результат -> и возвращает результат обратно клиенту в виде HTML-страницы (просмотр) '.
Что если мы говорим о чистом веб-сервисе API RESTful? Затем поток с чем-то вроде ' клиент отправляет запрос ключевого слова REST на сервер -> сервер сопоставляет запрошенный URL с действием контроллера ->, который затем вызывает модель (ы) для сбора / обработки данных, получает результат -> и возвращает результат обратно клиенту в JSON'е . То же самое, что и раньше, но «представления» нет ... или, скорее, сгенерированный JSON можно рассматривать как «представление». В некотором смысле, мы используем только часть MC MVC. Так ли это должно быть сделано? Или есть другие, более подходящие шаблоны для службы только API вместо MVC?
источник
Вид - это слой, отвечающий за отображение информации, которая может быть интерпретирована пользователем / клиентом вашего приложения (это не означает, что пользователь должен быть реальным человеком). JSON - полностью допустимый формат для слоя представления, компьютеры понимают это.
Пока слой представления публикует информацию, которая может использоваться пользователем для воздействия на модели в вашем приложении, не имеет значения, как выглядит представление, это все еще представление, уровень, выполняющий роль промежуточного программного обеспечения между пользователем и системой ,
источник
Мартин Фаулер, возможно, не согласится с этим :
Двигаемся дальше ...
Хорошо, это немного путаница
MVC, каким бы он ни был, представляет собой набор идей для реализации пользовательских интерфейсов.
REST - это набор архитектурных ограничений для построения крупномасштабных приложений.
Сеть, о которой вы здесь говорите, представляет собой гигантское приложение для управления документами, созданное с использованием большинства тех же ограничений.
Сходства, которые вы видите между ними, неверно приписаны (на ваш выбор) или поверхностны.
У RESTafarians есть общее понимание HATEOAS , «гипертекста как движка состояния приложения», и это должно посылать сигналы тревоги, звучащие у вас в голове - почему представление будет двигателем состояния ? Если мы подвергаем сомнению предпосылку и ищем дополнительные доказательства, мы также можем заметить две странные вещи.
Во-первых, мы можем полностью вывести HTTP-сервер из уравнения, загрузив HTML-код с диска. Браузер полностью доволен этим, исключая некоторые незначительные изменения в поведении, которые могут возникнуть в результате изменения базового URL. Представления обычно не продолжают работать, когда они полностью отключены от модели и контроллера.
Во-вторых, если мы внимательно наблюдаем за современным браузером, мы заметим, что существует несколько представлений HTML. Многократные представления представления кажутся действительно странной идеей, но, конечно же, есть основная презентация с кучей текстовой разметки, которая реагирует на жесты пользователя, а затем есть такая вещь «Представление источника», которая показывает необработанный HTML и также отвечает на пользовательские жесты. Это черепахи вниз!
Ответ на загадку, конечно же, заключается в том, что HTML - это не представление. Коллекция виджетов в браузере является представлением, и они взаимодействуют с объектной моделью документа , которая была инициализирована чтением HTML.
Другими словами, HTML является представлением состояния, как и обещал Рой Т. Филдинг .
Вернее, так же, как и раньше: зрения нет. JSON, как и HTML, является представлением состояния, подходящим для пересечения границ процесса.
Подумайте «DTO» или «Сообщение», и вы сделаете выводы, что с гораздо меньшей вероятностью приведет вас в заблуждение.
источник
Передача JSON в качестве представления или использование его в качестве модели представления для создания представления не нарушает шаблон.
Я использую ту же архитектуру в текущем приложении, над которым я работаю, и это работает очень хорошо. Вместе с некоторыми хорошими JS-фреймворками вы можете создавать действительно адаптивные проекты.
Честно говоря, не знаю. Но я думаю, что не важно, используете ли вы MVC или нет в API. Используйте то, что вы считаете удобным. Говоря о веб-сервисах, необходимо учитывать гораздо более важные аспекты (которые не имеют прямого отношения к MVC), например, безопасность, согласованность, доступность и т. Д.
источник