MVC非常简单。有一个模型，一个控制器和一个视图。当我们创建一个网站时，这一切都将作为一个整体' 客户端向服务器发送REST关键字请求->服务器将请求的URL与控制器操作相匹配->然后调用模型进行数据收集/处理，以获取结果->并将结果作为HTML页面（视图）返回给客户端。
如果我们正在谈论纯RESTful API Web服务该怎么办？然后，流程类似于“ 客户端向服务器发送REST关键字请求->服务器将请求的URL匹配到控制器操作->然后调用模型进行数据收集/处理，获得结果->并返回结果以JSON ' 返回给客户端。与以前相同，但是没有“视图” ...或者，可以将生成的JSON视为“视图”。从某种意义上讲，我们仅在利用MVC的MC部分。那是应该怎么做的？还是对于仅API服务而不是MVC还有其他更合适的模式吗？
Answers:
MVC是Smalltalk世界中的一个范例，它涉及面向对象的系统如何具有UI。
早期的Web框架采用了总体思想（将业务逻辑，控制逻辑和视图逻辑分开），并将其原理应用到它们如何构成Web应用程序中。在此之前，在域对象中包含大量糟糕的HTML生成代码，或者在HTML模板中包含业务逻辑的情况并不罕见（请考虑非常早的PHP）
事实是，来自Smalltalk世界的原始MVC并不是大多数Web框架中的MVC。从Smalltalk理解UI屏幕的意义上来说，HTML输出并不是真正的“视图”。
因此，这是您不要过于关注是否正确遵循MVC的第一个原因。几乎没有。如果我们的HTML模板没有完整的业务逻辑，那么把它当作严格的划分而不是一个严格的Hey准则就不好了。
其次，MVC只是一种构造服务器端代码的方式。它确实与REST / HTTP无关。REST与客户端和服务器之间的通信方式有关。不管服务器发送给客户端的表示形式是使用模板模板引擎花费大量时间来构建模板的HTML模板，还是使用控制器中一次调用的JSON对象。
如果您不认为您的服务器需要一个“视图”层就可以了。从所有处理特定HTTP请求的控制器中分离出您的业务逻辑（即模型），即使所有控制器都对某个对象调用JSON解析调用并返回该数据，您仍然会受益。
MVC非常简单。
马丁·福勒（Martin Fowler）可能不同意这一点：
在不同地方阅读有关MVC的不同人士会从中获得不同的想法，并将其描述为“ MVC”。
继续...
当我们创建一个网站时，所有这些都将合并在一起，因为“客户端将REST关键字请求发送到服务器->服务器将请求的URL与控制器操作相匹配->然后调用该模型进行数据收集/处理，以获取结果->并将结果作为HTML页面（视图）返回给客户端。
好，这有点纠结
无论是什么，MVC都是用于实现用户界面的想法的集合。
REST是用于构建大型应用程序的体系结构约束的集合。
Web是您在这里谈论的内容，它是一个使用大多数相同约束构建的巨型文档管理应用程序。
您发现两者之间的相似性是错误地归因于（表面上）或是肤浅的。
RESTafarians对HATEOAS有一个共同的理解，HATEOAS是“超文本作为应用程序状态的引擎”，并且应该发送警报响彻您的头顶-为什么视图将成为状态引擎？如果我们质疑前提，并寻找其他证据，我们可能还会注意到两件奇怪的事情。
首先，通过从磁盘加载HTML，我们可以完全摆脱HTTP服务器的困扰。浏览器对此非常满意，可以免除基本URL更改可能引起的行为上的细微变化。当视图与模型和控制器完全断开时，它们通常不会继续起作用。
其次，如果我们仔细观察现代浏览器，就会发现HTML有多个视图。视图的多个视图似乎是一个非常奇怪的主意，但可以肯定的是，主要的演示文稿带有一堆响应用户手势的文本标记，然后有一个“源代码视图”，它显示了原始HTML并也响应了用户手势。一直都是乌龟！
谜语的答案当然是HTML不是视图。浏览器中的小部件集合是视图，它们与通过读取HTML初始化的Document Object Model通信。
换句话说，HTML是状态的表示，就像Roy T. Fielding承诺的那样。
如果我们谈论的是纯RESTful API Web服务...该怎么办？与以前相同，但是没有“视图”
更正确的是，与以前相同：没有视图。就像HTML一样，JSON是状态的一种表示形式，适用于跨越流程边界。
想想“ DTO”或“消息”，您的推论将不太可能使您误入歧途。