随着互联网的高速发展，前端页面的展示、交互体验越来越灵巧、炫丽，相应体验也哀求越来越高，后端做事的高并发、高可用、高性能、高扩展等特性的哀求也愈加苛刻，从而导致前后端研发各自专注于自己善于的领域深耕细作。
然而带来的另一个问题：前后真个对接界面双方却关注甚少，没有任何接口约定规范情形下各自干各自的，导致我们在产品项目开拓过程中，前后真个接口联调对接事情量占比在30%-50%旁边，乃至会更高。每每前后端接口联调对接及系统间的联调对接都是全体产品项目研发的软肋。
本文的紧张初衷便是规范约定先行，只管即便避免沟通联调产生的不必要的问题，让大家身心愉快地专注于各自善于的领域。
2. 为何要分离
参考两篇文章：
http://blog.jobbole.com/65509/http://blog.jobbole.com/56161/
目前现有前后端开拓模式：“后端为主的MVC时期”，如下图所示：
后端为主的MVC时期
代码可掩护性得到明显好转，MVC 是个非常好的协作模式，从架构层面让开发者懂得什么代码该当写在什么地方。为了让 View 层更大略干脆，还可以选择 Velocity、Freemaker 等模板，使得模板里写不了 Java 代码。
看起来是功能变弱了，但正是这种限定使得前后端分工更清晰。然而依旧并不是那么清晰，这个阶段的范例问题是：
前端开拓重度依赖开拓环境，开拓效率低。
这种架构下，前后端协作有两种模式：一种是前端写demo，写好后，让后端去套模板 。淘宝早期包括现在依旧有大量业务线是这种模式。好处很明显，demo 可以本地开拓，很高效。不敷是还须要后端套模板，有可能套错，套完后还须要前端确定，来回沟通调度的本钱比较大。
另一种协作模式是前端卖力浏览器真个所有开拓和做事器真个 View 层模板开拓，支付宝是这种模式。好处是 UI 干系的代码都是前端去写就好，后端不用太关注，不敷便是前端开拓重度绑定后端环境，环境成为影响前端开拓效率的主要成分。
前后端职责依旧牵丝扳藤。
Velocity 模板还是蛮强大的，变量、逻辑、宏等特性，依旧可以通过拿到的高下文变量来实现各种业务逻辑。这样，只要前端弱势一点，每每就会被后端哀求在模板层写出不少业务代码。还有一个很大的灰色地带是 Controller，页面路由等功能本该当是前端最关注的，但却是由后端来实现。Controller 本身与 Model 每每也会牵丝扳藤，看了让人咬牙的业务代码常常会涌如今 Controller 层。这些问题不能全归结于程序员的素养，否则 JSP 就够了。
对前端发挥的局限。
性能优化如果只在前端做空间非常有限，于是我们常常须要后端互助才能碰撞出火花，但由于后端框架限定，我们很难利用Comet、Bigpipe等技能方案来优化性能。
总上所述，就跟为什麽要代码重构一样：
关注点分离职责分离对的人做对的事更好的共建模式快速的反应变革3. 什么是分离
我们现在要做的前后分离第一阶段：“基于 Ajax 带来的 SPA 时期”，如图：
基于 Ajax 带来的 SPA 时期
这种模式下，前后真个分工非常清晰，前后真个关键协作点是 Ajax 接口。看起来是如此美妙，但回过分来看看的话，这与 JSP 时期差异不大。繁芜度从做事真个 JSP 里移到了浏览器的 JavaScript，浏览器端变得很繁芜。类似 Spring MVC，这个时期开始涌现浏览器真个分层架构：
浏览器真个分层架构
对付这一SPA阶段，前后端分离有几个主要寻衅：
前后端接口的约定。
如果后真个接口一塌糊涂，如果后真个业务模型不足稳定，那么前端开拓会很痛楚。这一块在业界有 API Blueprint 等方案来约定和沉淀接口，==在阿里，不少团队也有类似考试测验，通过接口规则、接口平台等办法来做。有了和后端一起沉淀的接口规则，还可以用来仿照数据，使得前后端可以在约定接口后实现高效并行开拓。== 相信这一块会越做越好。
前端开拓的繁芜度掌握。
SPA 运用大多以功能交互型为主，JavaScript 代码过十万行很正常。大量 JS 代码的组织，与 View 层的绑定等，都不是随意马虎的事情。范例的办理方案是业界的 Backbone，但 Backbone 做的事还很有限，依旧存在大量空缺区域须要寻衅。
4. 如何做分离
4.1 职责分离
职责分离
前后端仅仅通过异步接口(AJAX/JSONP)来编程前后端都各自有自己的开拓流程，构建工具，测试凑集关注点分离，前后端变得相对独立并松耦合4.2 开拓流程
后端编写和掩护接口文档，在 API 变革时更新接口文档后端根据接口文档进行接口开拓前端根据接口文档进行开拓 + Mock平台开拓完成后联调和提交测试Mock 做事器根据接口文档自动天生 Mock 数据，实现了接口文档即API：
开拓流程
4.3 详细履行
现在已基本完成了，接口方面的履行：
接口文档做事器：可实现接口变更实时同步给前端展示；Mock接口数据平台：可实现接口变更实时Mock数据给前端利用；接口规范定义：很主要，接口定义的好坏直接影响到前真个事情量和实现逻辑；详细定义规范见下节；接口文档+Mock平台做事器
5. 接口规范V1.0.0
5.1 规范原则
接口返回数据即显示：前端仅做渲染逻辑处理；渲染逻辑禁止跨多个接口调用；前端关注交互、渲染逻辑，只管即便避免业务逻辑处理的涌现；要求相应传输数据格式：JSON，JSON数据只管即便大略轻量，避免多级JSON的涌现；5.2 基本格式
5.2.1 要求基本格式
GET要求、POST要求==必须包含key为body的入参，所有要求数据包装为JSON格式，并存放到入参body中==，示例如下：
GET要求：
xxx/login?body={"username":"admin","password":"123456","captcha":"scfd","rememberMe":1}
POST要求：
5.2.2 相应基本格式
{ code: 200, data: { message: "success" }}
code : 要求处理状态
200: 要求处理成功500: 要求处理失落败401: 要求未认证，跳转登录页406: 要求未授权，跳转未授权提示页data.message: 要求处理
code=200 且 data.message="success": 要求处理成功code=200 且 data.message!="success": 要求处理成功, 普通提示：message内容code=500: 要求处理失落败，警告提示：message内容5.3 相应实体格式
{ code: 200, data: { message: "success", entity: { id: 1, name: "XXX", code: "XXX" } }}
data.entity: 相应返回的实体数据
5.4 相应列表格式
data.list: 相应返回的列表数据
5.5 相应分页格式
{ code: 200, data: { recordCount: 2, message: "success", totalCount: 2, pageNo: 1, pageSize: 10, list: [ { id: 1, name: "XXX", code: "H001" }, { id: 2, name: "XXX", code: "H001" } ], totalPage: 1 }}
data.recordCount: 当前页记录数data.totalCount: 总记录数data.pageNo: 当前页码data.pageSize: 每页大小data.totalPage: 总页数5.6 分外内容规范
5.6.1 下拉框、复选框、单选框
由后端接口统一逻辑剖断是否选中，通过isSelect标示是否选中，示例如下：
{ code: 200, data: { message: "success", list: [{ id: 1, name: "XXX", code: "XXX", isSelect: 1 }, { id: 1, name: "XXX", code: "XXX", isSelect: 0 }] }}
禁止下拉框、复选框、单选框剖断选中逻辑由前端来处理，统一由后端逻辑剖断选中返回给前端展示；
5.6.2 Boolean类型
关于Boolean类型，JSON数据传输中一律利用1/0来标示，1为是/True，0为否/False；
5.6.3 日期类型
关于日期类型，JSON数据传输中一律利用字符串，详细日期格式因业务而定；
6. 未来的大前端
目前我们现在用的前后端分离模式属于第一阶段，由于利用到的一些技能jquery等，对付一些页面展示、数据渲染还是比较繁芜，不能够很好的达到复用。对付前端还是有很大的事情量。
下一阶段可以在前端工程化方面，对技能框架的选择、前端模块化重用方面，可多做考量。也便是要迎来“==前端为主的 MV 时期==”。大多数的公司也基本都处于这个分离阶段。
末了阶段便是==Node 带来的全栈时期==，完备有前端来掌握页面，URL，Controller，路由等，后真个运用就逐步弱化为真正的数据做事+业务做事，做且仅能做的是供应数据、处理业务逻辑，关注高可用、高并发等。
这两个阶段仅做大略先容，有兴趣的可以参考下面的资料。
