1. 前言
随着互联网的高速倒退，前端页面的展现、交互体验越来越灵便、炫丽，响应体验也要求越来越高，后端服务的高并发、高可用、高性能、高扩大等个性的要求也更加刻薄，从而导致前后端研发各自专一于本人善于的畛域深耕细作。
然而带来的另一个问题：前后端的对接界面单方却关注甚少，没有任何接口约定标准状况下各自撸起袖子就是干，导致咱们在产品我的项目开发过程中，前后端的接口联调对接
工作量占比在30%-50%左右，甚至会更高。往往前后端接口联调对接及零碎间的联调对接都是整个产品我的项目研发的软肋。
本文的次要初衷就是标准约定后行，尽量避免沟通联调产生的不必要的问题，让大家身心愉快地专一于各自善于的畛域。
2. 为何要拆散
目前现有前后端开发模式：“后端为主的MVC时代”，如下图所示：
代码可维护性失去明显好转，MVC 是个十分好的合作模式，从架构层面让开发者懂得什么代码应该写在什么中央。为了让 View 层更简略罗唆，还能够抉择 Velocity、Freemaker 等模板，使得模板里写不了 Java 代码。看起来是性能变弱了，但正是这种限度使得前后端分工更清晰。然而仍旧并不是那么清晰，这个阶段的典型问题是：
- 前端开发重度依赖开发环境，开发效率低。这种架构下，前后端合作有两种模式：一种是前端写demo，写好后，让后端去套模板 。淘宝晚期包含当初仍旧有大量业务线是这种模式。益处很显著，demo 能够本地开发，很高效。有余是还须要后端套模板，有可能套错，套完后还须要前端确定，来回沟通调整的老本比拟大。另一种合作模式是前端负责浏览器端的所有开发和服务器端的 View 层模板开发，支付宝是这种模式。 益处是 UI 相干的代码都是前端去写就好，后端不必太关注，有余就是前端开发重度绑定后端环境，环境成为影响前端开发效率的重要因素。
- 前后端职责仍旧纠缠不清。 Velocity 模板还是蛮弱小的，变量、逻辑、宏等个性，仍旧能够通过拿到的上下文变量来实现各种业务逻辑。这样，只有前端弱势一点，往往就会被后端要求在模板层写出不少业务代码。还有一个很大的灰色地带是 Controller，页面路由等性能本应该是前端最关注的，但却是由后端来实现。 Controller 自身与 Model 往往也会纠缠不清，看了让人咬牙的业务代码常常会呈现在 Controller 层。这些问题不能全归纳于程序员的素养，否则 JSP 就够了。
- 对前端施展的局限。 性能优化如果只在前端做空间十分无限，于是咱们常常须要后端单干能力碰撞出火花，但因为后端框架限度，咱们很难应用Comet、Bigpipe等技术计划来优化性能。
总上所述，就跟為什麼要代碼重構一樣：
- 关注点拆散
- 职责拆散
- 对的人做对的事
- 更好的共建模式
- 疾速的反馈变动
3. 什么是拆散
咱们当初要做的前后拆散第一阶段：“基于 Ajax 带来的 SPA 时代”，如图：
这种模式下，前后端的分工十分清晰，前后端的要害合作点是 Ajax 接口。 看起来是如此美好，但回过头来看看的话，这与 JSP 时代区别不大。复杂度从服务端的 JSP 里移到了浏览器的 JavaScript，浏览器端变得很简单。相似 Spring MVC，这个时代开始呈现浏览器端的分层架构：
对于这一SPA阶段，前后端拆散有几个重要挑战：
- 前后端接口的约定。 如果后端的接口一塌糊涂，如果后端的业务模型不够稳固，那么前端开发会很苦楚。这一块在业界有 API Blueprint 等计划来约定和积淀接口，==在阿里，不少团队也有相似尝试，通过接口规定、接口平台等形式来做。有了和后端一起积淀的接口规定，还能够用来模仿数据，使得前后端能够在约定接口后实现高效并行开发。== 置信这一块会越做越好。
- 前端开发的复杂度管制。 SPA 利用大多以性能交互型为主，JavaScript 代码过十万行很失常。大量 JS 代码的组织，与 View 层的绑定等，都不是容易的事件。典型的解决方案是业界的 Backbone，但 Backbone 做的事还很无限，仍旧存在大量空白区域须要挑战。
4. 如何做拆散
4.1 职责拆散
- 前后端仅仅通过异步接口(AJAX/JSONP)来编程
- 前后端都各自有本人的开发流程，构建工具，测试汇合
- 关注点拆散，前后端变得绝对独立并松耦合
| 后端 | 前端 |
|---|---|
| 提供数据 | 接收数据，返回数据 |
| 解决业务逻辑 | 解决渲染逻辑 |
| Server-side MVC架构 | Client-side MV* 架构 |
| 代码跑在服务器上 | 代码跑在浏览器上 |
4.2 开发流程
- 后端编写和保护接口文档，在 API 变动时更新接口文档
- 后端依据接口文档进行接口开发
- 前端依据接口文档进行开发 + Mock平台
- 开发实现后联调和提交测试
Mock 服务器依据接口文档主动生成 Mock 数据，实现了接口文档即API：
4.3 具体实施
当初已根本实现了，接口方面的施行：
- 接口文档服务器：可实现接口变更实时同步给前端展现；
- Mock接口数据平台：可实现接口变更实时Mock数据给前端应用；
- 接口标准定义：很重要，接口定义的好坏间接影响到前端的工作量和实现逻辑；具体定义标准见下节；
5. 接口标准V1.0.0
5.1 标准准则
- 接口返回数据即显示：前端仅做渲染逻辑解决；
- 渲染逻辑禁止跨多个接口调用；
- 前端关注交互、渲染逻辑，尽量避免业务逻辑解决的呈现；
- 申请响应传输数据格式：JSON，JSON数据尽量简略轻量，防止多级JSON的呈现；
5.2 根本格局
5.2.1 申请根本格局
GET申请、POST申请==必须蕴含key为body的入参，所有申请数据包装为JSON格局，并存放到入参body中==，示例如下：
1. GET申请：
xxx/login?body={"username":"admin","password":"123456","captcha":"scfd","rememberMe":1}2. 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 响应列表格局
{ code: 200, data: { message: "success", list: [ { id: 1, name: "XXX", code: "XXX" }, { id: 2, name: "XXX", code: "XXX" } ] }}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数据传输中一律应用字符串，具体日期格局因业务而定；
最初
欢送大家关注我的公众号：前程有光，金三银四跳槽面试季，整顿了1000多道将近500多页pdf文档的Java面试题材料，文章都会在外面更新，整顿的材料也会放在外面。