先后端分离三连问：为什么分离？如何分离？分离后的接口规范？

• 1. 前言

• 2. 为什么要分离

• 3. 什么是分离

• 4. 如何作分离

• 5. 接口规范V1.0.0

• 6. 将来的大前端

1. 前言

随着互联网的高速发展，前端页面的展现、交互体验愈来愈灵活、炫丽，响应体验也要求愈来愈高，后端服务的高并发、高可用、高性能、高扩展等特性的要求也越发苛刻，从而致使先后端研发各自专一于本身擅长的领域深耕细做

然而带来的另外一个问题：先后端的对接界面双方却关注甚少，没有任何接口约定规范状况下各自干各自的.

这致使咱们在产品项目开发过程当中，先后端的接口联调对接工做量占比在30%-50%左右，甚至会更高。每每先后端接口联调对接及系统间的联调对接都是整个产品项目研发的软肋。

本文的主要初衷就是规范约定先行，尽可能避免沟通联调产生的没必要要的问题，让你们身心愉快地专一于各自擅长的领域。

2. 为什么要分离

参考两篇文章：

http://blog.jobbole.com/65509/
http://blog.jobbole.com/56161/

目前现有先后端开发模式：“后端为主的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)来编程
  

• 先后端都各自有本身的开发流程，构建工具，测试集合

• 关注点分离，先后端变得相对独立并松耦合

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中==，示例以下：

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 响应分页格式

• data.recordCount: 当前页记录数

• data.totalCount: 总记录数

• data.pageNo: 当前页码

• data.pageSize: 每页大小

• data.totalPage: 总页数

5.6 特殊内容规范

5.6.1 下拉框、复选框、单选框

由后端接口统一逻辑断定是否选中，经过isSelect标示是否选中，示例以下：

禁止下拉框、复选框、单选框断定选中逻辑由前端来处理，统一由后端逻辑断定选中返回给前端展现；

5.6.2 Boolean类型

关于Boolean类型，JSON数据传输中一概使用1/0来标示，1为是/True，0为否/False；

5.6.3 日期类型

关于日期类型，JSON数据传输中一概使用字符串，具体日期格式因业务而定；

6. 将来的大前端

目前咱们如今用的先后端分离模式属于第一阶段，因为使用到的一些技术jquery等，对于一些页面展现、数据渲染仍是比较复杂，不可以很好的达到复用。对于前端仍是有很大的工做量。

下一阶段能够在前端工程化方面，对技术框架的选择、前端模块化重用方面，可多作考量。也就是要迎来“前端为主的 MV* 时代”。大多数的公司也基本都处于这个分离阶段。

最后阶段就是Node 带来的全栈时代，彻底有前端来控制页面，URL，Controller，路由等，后端的应用就逐步弱化为真正的数据服务+业务服务，作且仅能作的是提供数据、处理业务逻辑，关注高可用、高并发等。

END

长按下图二维码，即刻关注【狸猫技术窝】

阿里、京东、美团、字节跳动 顶尖技术专家坐镇

为IT人打造一个 “有温度” 的技术窝！