随着互联网的高速发展,前端页面的展示、交互体验越来越灵活、炫丽,响应体验也要求越来越高,后端服务的高并发、高可用、高性能、高扩展等特性的要求也愈加苛刻,从而导致前后端研发各自专注于自己擅长的领域深耕细作。
然而带来的另一个问题:前后端的对接界面双方却关注甚少,没有任何接口约定规范情况下各自撸起袖子就是干,导致我们在产品项目开发过程中,前后端的接口联调对接。 工作量占比在30%-50%左右,甚至会更高。往往前后端接口联调对接及系统间的联调对接都是整个产品项目研发的软肋。
本文的主要初衷就是规范约定先行,尽量避免沟通联调产生的不必要的问题,让大家身心愉快地专注于各自擅长的领域。
我们现在要做的前后分离第一阶段:“基于 Ajax 带来的 SPA 时代”,如图:
这种模式下,前后端的分工非常清晰,前后端的关键协作点是 Ajax 接口。 看起来是如此美妙,但回过头来看看的话,这与 JSP 时代区别不大。复杂度从服务端的 JSP 里移到了浏览器的 JavaScript,浏览器端变得很复杂。类似 Spring MVC,这个时代开始出现浏览器端的分层架构:
对于这一SPA阶段,前后端分离有几个重要挑战:
参考两篇文章《Web 研发模式的演变》、《Web应用的组件化开发》, 目前现有前后端开发模式:“后端为主的MVC时代”,如下图所示:
代码可维护性得到明显好转,MVC 是个非常好的协作模式,从架构层面让开发者懂得什么代码应该写在什么地方。为了让 View 层更简单干脆,还可以选择 Velocity、Freemaker 等模板,使得模板里写不了 Java 代码。看起来是功能变弱了,但正是这种限制使得前后端分工更清晰。然而依旧并不是那么清晰,这个阶段的典型问题是:
总上所述,就跟為什麼要代碼重構一樣:
职责分离
后端 | 前端 |
---|---|
提供数据 | 接收数据,返回数据 |
处理业务逻辑 | 处理渲染逻辑 |
Server-side MVC架构 | Client-side MV* 架构 |
代码跑在服务器上 | 代码跑在浏览器上 |
Mock 服务器根据接口文档自动生成 Mock 数据,实现了接口文档即API:
开发流程
现在已基本完成了,接口方面的实施:
接口文档+Mock平台服务器
GET请求、POST请求必须包含key为body的入参,所有请求数据包装为JSON格式,并存放到入参body中,示例如下:
xxx/login?body={“username”:“admin”,“password”:“123456”,“captcha”:“scfd”,“rememberMe”:1}
POST请求
{
code: 200,
data: {
message: "success"
}
}
200: 请求处理成功 500: 请求处理失败 401: 请求未认证,跳转登录页 406: 请求未授权,跳转未授权提示页
code=200 且 data.message=“success”: 请求处理成功 code=200 且 data.message!=“success”: 请求处理成功, 普通消息提示:message内容 code=500: 请求处理失败,警告消息提示:message内容
{
code: 200,
data: {
message: "success",
entity: {
id: 1,
name: "XXX",
code: "XXX"
}
}
}
data.entity: 响应返回的实体数据
{
code: 200,
data: {
message: "success",
list: [
{
id: 1,
name: "XXX",
code: "XXX"
},
{
id: 2,
name: "XXX",
code: "XXX"
}
]
}
}
data.list: 响应返回的列表数据
{
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: 总页数
由后端接口统一逻辑判定是否选中,通过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数据传输中一律使用字符串,具体日期格式因业务而定;