随着互联网的高速发展，前端页面的展示、交互体验越来越灵活、炫丽，响应体验也要求越来越高，后端服务的高并发、高可用、高性能、高扩展等特性的要求也愈加苛刻，从而导致前后端研发各自专注于自己擅长的领域深耕细作。
然而带来的另一个问题：前后端的对接界面双方却关注甚少，没有任何股票交易接口源码,接口约定规范情况下各自撸起袖子就是干，导致我们在产品项目开发过程中，前后端的股票交易接口源码,接口联调对接工作量占比在30%-50%左右，甚至会更高。往往前后端股票交易接口源码,接口联调对接及系统间的联调对接都是整个产品项目研发的软肋。
本文的主要初衷就是规范约定先行，尽量避免沟通联调产生的不必要的问题，让大家身心愉快地专注于各自擅长的领域。
为何要分离
参考两篇文章
目前现有前后端开发模式：“后端为主的MVC时代”，如下所示：
后端为主的MVC时代
代码可维护性得到明显好转，MVC是个非常好的协作模式，从架构层面让开发者懂得什么代码应该写在什么地方。为了让View层更简单干脆，还可以选择Velocity、Freemaker等模板，使得模板里写不了Java代码。看起来是功能变弱了，但正是这种限制使得前后端分工更清晰。然而依旧并不是那么清晰，这个阶段的典型问题是：
前端开发重度依赖开发环境，开发效率低。这种架构下，前后端协作有两种模式：一种是前端写demo，写好后，让后端去套模板。淘宝早期包括现在依旧有大量业务线是这种模式。好处很明显，demo可以本地开发，很高效。不足是还需要后端套模板，有可能套错，套完后还需要前端确定，来回沟通调整的成本比较大。另一种协作模式是前端负责浏览器端的所有开发和服务器端的View层模板开发，支付宝是这种模式。好处是UI相关的代码都是前端去写就好，后端不用太关注，不足就是前端开发重度绑定后端环境，环境成为影响前端开发效率的重要因素。前后端职责依旧纠缠不清。Velocity模板还是蛮强大的，变量、逻辑、宏等特性，依旧可以通过拿到的上下文变量来实现各种业务逻辑。这样，只要前端弱势一点，往往就会被后端要求在模板层写出不少业务代码。还有一个很大的灰色地带是Controller，页面路由等功能本应该是前端最关注的，但却是由后端来实现。Controller本身与Model往往也会纠缠不清，看了让人咬牙的业务代码经常会出现在Controller层。这些问题不能全归结于程序员的素养，否则JSP就够了。对前端发挥的局限。性能优化如果只在前端做空间非常有限，于是我们经常需要后端合作才能碰撞出火花，但由于后端框架限制，我们很难使用Comet、Bigpipe等技术方案来优化性能。
总上所述，就跟為什麼要代碼重構一樣：
关注点分离职责分离对的人做对的事更好的共建模式快速的反应变化
什么是分离
我们现在要做的前后分离第一阶段：“基于Ajax带来的SPA时代”，如：
基于Ajax带来的SPA时代
这种模式下，前后端的分工非常清晰，前后端的关键协作点是Ajax股票交易接口源码,接口。看起来是如此美妙，但回过头来看看的话，这与JSP时代区别不大。复杂度从服务端的JSP里移到了浏览器的JavaScript，浏览器端变得很复杂。类似SpringMVC，这个时代开始出现浏览器端的分层架构：
浏览器端的分层架构
对于这一SPA阶段，前后端分离有几个重要挑战：
前后端股票交易接口源码,接口的约定。如果后端的股票交易接口源码,接口一塌糊涂，如果后端的业务模型不够稳定，那么前端开发会很痛苦。这一块在业界有APIBlueprint等方案来约定和沉淀股票交易接口源码,接口，==在阿里，不少团队也有类似尝试，通过股票交易接口源码,接口规则、股票交易接口源码,接口平台等方式来做。有了和后端一起沉淀的股票交易接口源码,接口规则，还可以用来模拟数据，使得前后端可以在约定股票交易接口源码,接口后实现高效并行开发。==相信这一块会越做越好。前端开发的复杂度控制。SPA应用大多以功能交互型为主，JavaScript代码过十万行很正常。大量JS代码的组织，与View层的绑定等，都不是容易的事情。典型的解决方案是业界的Backbone，但Backbone做的事还很有限，依旧存在大量空白区域需要挑战。
如何做分离
职责分离
职责分离
前后端仅仅通过异步股票交易接口源码,接口(AJAX/JSONP)来编程前后端都各自有自己的开发流程，构建工具，测试集合关注点分离，前后端变得相对独立并松耦合
开发流程
后端编写和维护股票交易接口源码,接口文档，在API变化时更新股票交易接口源码,接口文档后端根据股票交易接口源码,接口文档进行股票交易接口源码,接口开发前端根据股票交易接口源码,接口文档进行开发+Mock平台开发完成后联调和提交测试
Mock服务器根据股票交易接口源码,接口文档自动生成Mock数据，实现了股票交易接口源码,接口文档即API：
开发流程
具体实施
现在已基本完成了，股票交易接口源码,接口方面的实施：
股票交易接口源码,接口文档服务器：可实现股票交易接口源码,接口变更实时同步给前端展示；Mock股票交易接口源码,接口数据平台：可实现股票交易接口源码,接口变更实时Mock数据给前端使用；股票交易接口源码,接口规范定义：很重要，股票交易接口源码,接口定义的好坏直接影响到前端的工作量和实现逻辑；具体定义规范见下节；
股票交易接口源码,接口文档+Mock平台服务器
股票交易接口源码,接口规范V0.0
规范原则
股票交易接口源码,接口返回数据即显示：前端仅做渲染逻辑处理；渲染逻辑禁止跨多个股票交易接口源码,接口调用；前端关注交互、渲染逻辑，尽量避免业务逻辑处理的出现；请求响应传输数据格式：JSON，JSON数据尽量简单轻量，避免多级JSON的出现；
基本格式
请求基本格式
GET请求、POST请求==必须包含key为body的入参，所有请求数据包装为JSON格式，并存放到入参body中==，示例如下：
GET请求：
xxx/login?body={'username':'admin','password':'123456','captcha':'scfd','rememberMe':1}
POST请求：POST请求
响应基本格式
{
code: 200,
data: {
message: 'success'
}
}
code:请求处理状态
00:请求处理成功500:请求处理失败401:请求未认证，跳转登录页406:请求未授权，跳转未授权提示页
datmessage:请求处理消息
code=200且datmessage='success':请求处理成功code=200且datmessage!='success':请求处理成功,普通消息提示：message内容code=500:请求处理失败，警告消息提示：message内容
响应实体格式
{
code: 200,
data: {
message: 'success',
entity: {
id: 1,
name: 'XXX',
code: 'XXX'
}
}
}
datentity:响应返回的实体数据
响应列表格式
{
code: 200,
data: {
message: 'success',
list: [
{
id: 1,
name: 'XXX',
code: 'XXX'
},
{
id: 2,
name: 'XXX',
code: 'XXX'
}
]
}
}
datlist:响应返回的列表数据
响应分页格式
{
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
}
}
datrecordCount:当前页记录数dattotalCount:总记录数datpageNo:当前页码datpageSize:每页大小dattotalPage:总页数
特殊内容规范
下拉框、复选框、单选框
由后端股票交易接口源码,接口统一逻辑判定是否选中，通过isSelect标示是否选中，示例如下：
{
code: 200,
data: {
message: 'success',
list: [{
id: 1,
name: 'XXX',
code: 'XXX',
isSelect: 1
}, {
id: 1,
name: 'XXX',
code: 'XXX',
isSelect: 0
}]
}
}
禁止下拉框、复选框、单选框判定选中逻辑由前端来处理，统一由后端逻辑判定选中返回给前端展示；
关于Boolean类型，JSON数据传输中一律使用1/0来标示，1为是/True，0为否/False；
日期类型
关于日期类型，JSON数据传输中一律使用字符串，具体日期格式因业务而定；
未来的大前端
目前我们现在用的前后端分离模式属于第一阶段，由于使用到的一些技术jquery等，对于一些页面展示、数据渲染还是比较复杂，不能够很好的达到复用。对于前端还是有很大的工作量。
下一阶段可以在前端工程化方面，对技术框架的选择、前端模块化重用方面，可多做考量。也就是要迎来“==前端为主的MV*时代==”。大多数的公司也基本都处于这个分离阶段。
最后阶段就是==Node带来的全栈时代==，完全有前端来控制页面，URL，Controller，路由等，后端的应用就逐步弱化为真正的数据服务+业务服务，做且仅能做的是提供数据、处理业务逻辑，关注高可用、高并发等。
这两个阶段仅做简单介绍，有兴趣的可以参考下面的资料。
参考资料
https://www.zhihu.com/question/28207685http://taobaofeorg/http://201jsconcn/slides/herman-taobaowebhttp://blojobbolcom/65509/https://blokaolafecom/http://blojobbolcom/65513/http://blojobbolcom/65534/http://blojobbolcom/65541/http://blojobbolcom/56161/
推荐好文
为什么MySQL不推荐使用uuid或者雪花id作为主键？
为什么建议大家使用Linux开发？爽
IntelliJIDEA15款神级超级牛逼插件推荐
炫酷，SpringBoot+Echarts实现用户访问地可视化
记一次由Redis分布式锁造成的重大事故，避免以后踩坑！
十分钟学会使用Elasticsearch优雅搭建自己的搜索系统
文章为作者独立观点，不代表观点
相关文章
股民评论