1.前言随着互联网的飞速发展，前端页面的展示和交互体验越来越灵活炫目，对响应式体验的要求也越来越高。对后端服务的高并发、高可用、高性能、高扩展性等特性的要求越来越高，导致前后端研发专注于自己擅长的领域。但是带来了另一个问题：双方都不太重视前后端的对接接口，各司其职，没有任何接口约定和规范。由此，在产品项目开发过程中，前后端联调对接工作量占比100%。大约30%-50%，甚至更高。往往前后端接口的联调对接、系统间的联调对接是整个产品项目开发的薄弱环节。写这篇文章的主要初衷是先规范一下协议，尽量避免交流和联调带来不必要的问题，让大家愉快的专注于各自擅长的领域。2、为什么要分离现有的前后端开发模式：“以后端为中心的MVC时代”，如下图：以后端为中心的MVC时代代码可维护性有明显提升，而MVC是一个非常好的协作模型，让开发者从架构层面就知道哪些代码应该写在什么地方。为了让View层更简洁明快，还可以选择Velocity、Freemaker等模板，这样模板中就不能写Java代码了。看似功能变弱了，但正是这种限制，让前后端分工更加明确。然而，目前还不是很清楚。这个阶段的典型问题是：前端开发对开发环境依赖严重，开发效率低下。在这种架构下，前后端协同有两种模式：一种是在前端写demo，写好后让后端套模板。在淘宝初期，还有大量的业务线在沿用这种模式。好处很明显，可以在本地开发demo，效率很高。缺点是模板需要在后台设置，有可能设置错。设置完成后需要前端确认，来回沟通调整成本比较高。另一种协作模式是前端负责浏览器端的所有开发，服务端的View层模板开发。支付宝就是这种模式。好处是所有UI相关的代码都是前端写的，后端不需要过多关注。缺点是前端开发严重绑定了后端环境，环境成为影响前端开发效率的重要因素。前端和后端的责任仍然纠缠在一起。Velocity模板还是很强大的。变量、逻辑、宏等特性仍然可以通过获取的上下文变量实现各种业务逻辑。这样一来，只要前端比较弱，往往会要求后端在模板层写大量的业务代码。另一个很大的灰色区域是控制器。页面路由之类的功能应该是前端最关心的，但是却被后端实现了。Controller本身和Model经常纠缠在一起，让人咬牙切齿的业务代码往往出现在Controller层。这些问题不能都归咎于程序员的素养，否则JSP就够了。前端播放的限制。如果只在前端做性能优化，空间是非常有限的，所以我们往往需要后端的配合才能擦出火花。但是由于后端框架的限制，我们很难使用Comet、Bigpipe等技术方案来优化性能。综上所述，和为什么需要代码重构是一样的：关注点分离责任分离合适的人做合适的事更好的共建模型快速响应变化阶段：“基于Ajax的SPA时代”，如图图：基于Ajax的SPA时代在这种模式下，前后端分工非常明确，前后端的关键协作点就是Ajax接口。看起来是那么的美好，但是回过头来看，和JSP时代并没有太大区别。复杂度从服务器端的JSP转移到了浏览器的JavaScript，浏览器端变得非常复杂。类似SpringMVC，浏览器端分层架构在这个时代开始出现：Browser-sidelayeredarchitecture对于这个SPA阶段，前后端分离有几个重要的挑战：和后端接口。如果后端接口一团糟，如果后端业务模型不够稳定，那么前端开发就会很痛苦。在这方面，业界有APIBlueprint等解决方案来约定和解决接口。==在阿里，很多团队都做了类似的尝试，通过接口规则、接口平台等方式，将接口规则和后端一起沉淀出来，也可以用来模拟数据，让前后端实现高效并行约定接口后进行开发。==相信这块会越来越好。前端开发的复杂度控制。大多数SPA应用以功能性和交互性为主，JavaScript代码超过10万行很正常。大量JS代码的组织，与View层的绑定等都不是一件容易的事。业界比较典型的解决方案是Backbone，但是Backbone能做的还很有限，还有很多空白需要去挑战。4.如何分离4.1职责分离前后端仅通过异步接口（AJAX/JSONP）进行编程。前端和后端都有自己的开发流程、构建工具和测试集合的关注点分离。前后端变得相对独立和松耦合4.2开发流程后端编写和维护接口文档，当API变化时更新接口文档后端根据接口文档开发接口前端根据接口文档+Mock平台开发完成后，联调提交测试根据接口文档自动生成Mock服务器Mock数据实现接口文档或API：开发流程4.3的具体实现至此基本完成，以及接口的实现：接口文档服务器：可以实时同步接口变化展示给前端；Mock接口数据平台：可实现实时接口变化Mock数据供前端使用；接口规范定义：非常重要，接口定义的好坏直接影响前端的工作量和实现逻辑；具体定义规范见下一节；接口文档+Mock平台服务器5.接口规范V1.0.05。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","re??memberMe":1}POST请求：5.2.2响应基本格式{code:200,data:{message:"success"}}code:请求处理状态200：请求处理成功500：请求处理失败401：请求未认证，跳转到登录页面406：请求未授权，跳转到未授权提示页面data.message：请求处理消息代码=200anddata.message="success"：请求处理成功code=200anddata.message!="success"：请求处理成功，正常消息提示：消息内容code=500：请求处理失败，警告消息提示:messageContent5.3Responseentityformat{code:200,data:{message:"success",entity:{id:1,name:"XXX",code:"XXX"}}}da??ta.entity:返回的实体数据response5.4响应列表格式data.list：响应返回的列表数据5.5响应分页格式{code:200,data:{recordCount:2,message:"success",totalCount:2,pageNo:1,pageSize:10,列表：[{id:1,name:"XXX",code:"H001"},{id:2,name:"XXX",code:"H001"}],totalPage:1}}data.recordCount:the当前页数据的记录数.totalCount：总记录数data.pageNo：当前页数data.pageSize：每页大小data.totalPage：总页数是否被选中由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类型，JSON数据传输总是使用1/0，1为Yes/True，0为No/False；5.6.3日期类型关于日期类型，JSON数据传输总是使用字符串。这取决于业务；6、未来的大前端我们目前使用的前后端分离模式属于第一阶段。由于使用了jquery等一些技术，一些页面展示和数据渲染还比较复杂，无法很好的实现。Reuse对于前端来说还是有很多工作要做的。下一阶段可以更多考虑前端工程化，技术框架的选择，前端模块化的复用。即迎来“==基于前端的MV*时代==”。大多数公司也基本处于这个分离阶段。最后阶段是==Node==带来的全栈时代，有前端控制页面、URL、Controller、路由等，后端应用逐渐弱化为真正的数据服务+业务服务，只能做的就是提供数据，处理业务逻辑，注重高可用，高并发等。
