注: 个人拙见，就事论事，如有另解，还望不吝斧正
前言
软件无论是从高层抽象还是底层实现，都是输入输出的过程。
如果你要实现a+b,会选择交给服务端做，还是客户端做？
MVC，传统BS架构项目首选模式，相对于CS架构项目，服务器需要做的事情更多了，接受输入数据（可能来源于请求、磁盘文件、数据库、内部维护的状态等），渲染（填写）view，返回客户端。
而客户端最主要的职责是解析html，结合css渲染页面，通过js实现交互、计算、数据请求或其他的一些事情。当然，浏览器为我们做了这些，这也是开发成本降低最主要的原因。
BS架构的流行的原因，或许源自以下优点
- 维护成本低
- 更新几乎是实时的，无需在新版本推出后更新客户端
- 业务、资源、服务集中，易于管理
- 服务不依赖于客户的操作系统、硬件资源
其中最后一条不晓得能不能算是优点，因为出现了浏览器，后端开发者将大多数工作放在了服务端，围绕程序员们的工作可能就是怎么处理业务逻辑、怎么应对高并发、怎么应对各种高效率读写。
而前端开发者的主要工作环境从某一操作系统的桌面环境迁移到了浏览器环境，编写html、css、js。处理用户的各种操作，并作出体验响应，将数据提交得到服务器响应，从而作出业务响应。
所以，后端关注用户群体验，前端关注用户体验。
REST API 架构的提出
一种软件架构风格，设计风格而不是标准，只是提供了一组设计原则和约束条件。它主要用于客户端和服务器交互类的软件。基于这个风格设计的软件可以更简洁，更有层次，更易于实现缓存等机制。
来源：百度百科
以javaEE中的jsp为例，我们想控制一个网页的标题，可以怎么做？
- 方案1
<html>
<head>
<title><% conf.title %></title>
</head>
<body></body>
</html>
conf对象或许会是上层业务逻辑提供的一个数据对象，由web容器对这个jsp进行渲染，最终输出为一段纯html代码给客户端。如下：
<html>
<head>
<title>网站标题</title>
</head>
<body></body>
</html>
- 方案2
以javaEE的servlet为例:
public class WebTitle extends HttpServlet{
public void doGet(HttpServletRequest request, HttpServletResponse response)14 throws ServletException, IOException{
response.write("网站标题");
}
}
编写html：
<html>
<head>
<title>获取失败</title>
</head>
<body>
<script src='jquery.min.js'></script>
<script>
//请求渲染数据
$.get('/WebTitle',function(data,tag){
if( tag == 'success' )
$('title').text(data);
});
</script>
</body>
</html>
这样就获取了标题数据，并渲染到title这个dom节点上了。
对比方案1与方案2不难发现，他们做同样的事情，主要的区别在于：数据谁来渲染(填写)？
js提供给前端开发人员逻辑表达的能力，除了操作dom做特效，同样也可以进行业务处理，较轻的业务逻辑可以不提交给服务器，动用客户浏览器的计算能力自行解决，对于数据敏感或者计算复杂的业务逻辑，可将请求提交至服务器来做，而传统的MVC几乎将所有的业务逻辑都放在后端去做，尽量忽略浏览器的计算能力，如dom通常不变换，不用局部刷新，不需要实时响应等。
各种MVC的框架，几乎处理了各种前后端交互的问题，各种渲染问题，但对于前后端的分离，以及前后端职责的问题总是弄不清楚，比如：让前端人员给后端html，后端人员“翻译为动态”的，这一过程属于成果共享，后端共享前端提交的代码，而修改后的结果需要前端去保证各种js，css执行正确，对于成果修改造成的任何后果，前后端都有责任，并且因为术业专攻的问题，而双方总要把手伸向自己不熟悉的领域，必然会影响开发效率。
REST API的出现，使得前后端分离问题比较好的解决。以下是个层级之间的情况。（JSON只是数据的一种表达方式，项目中可能会自选适用于当前应用场景的格式，流行的还有XML等格式）
| 层级 | 面向对象 | 主要业务 |
|---|---|---|
| 前端 | json体 | 处理请求,返回json |
| 后端 | 请求 | 处理用户交互,请求数据，渲染DOM节点 |
REST API 应用的意义
以下是笔者认为以REST API为架构的项目优势：
服务端业务基本处于稳定，不需要因服务想要进军其他平台而做太多改变。比如web端的功能做好了，想要做移动端，可以选择做APP享受本地系统资源（短信，照相，地理位置，存储），同时部分与本地资源无关的业务可直接与REST API交互，代价通常为想要进军的平台现有一个HTTP协议的实现或者自己实现，而服务端不需要做太大修改。
前后端工作均依赖接口，工作职责清晰，代码组织方式清晰。后端：输入请求，输出json。前端：输入json，输出视图相关内容（HTML CSS）
个人观点:一个应用只有不到5%的业务，非常需要依赖本地资源。程序及输入&输出，只是有时候，我们需要的输入不来仅仅自用户的键盘或鼠标输入，可能是用户的摄像头，可能是用户的话筒，等等，拓展到其他硬件平台也一样，一个应用依赖的是对数据的处理方式（业务逻辑），而这种方式通常都在服务端（本地应用除外）
REST API 相关技术栈推荐（针对个人开发者或小型开发团队，面向非高并发应用场景）
后端
- 数据存储层：Mysql Mongodb SQLServer
- 业务逻辑层： PHP JAVA ASP JS（node.js） 以及其他支持HTTP协议的，对JSON格式数据与自身语言相关数据结构体的转化代价较低的任何语言。
前端
- 渲染相关:JQuery Vue 其他（笔者没用过。。。）
- 后端数据交互: JQuery.ajax 其他（笔者没用过。。。）
