×
13518219792

建站动态

根据您的个性需求进行定制 先人一步 抢占小程序红利时代

谈谈前后分离接口规范

1. 前言

创新互联长期为千余家客户提供的网站建设服务，团队从业经验10年，关注不同地域、不同群体，并针对不同对象提供差异化的产品和服务；打造开放共赢平台，与合作伙伴共同营造健康的互联网生态环境。为青原企业提供专业的做网站、成都网站建设，青原网站改版等技术服务。拥有十余年丰富建站经验和众多成功案例,为您定制开发。

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

然而带来的另一个问题：前后端的对接界面双方却关注甚少，没有任何接口约定规范情况下各自干，导致我们在产品项目开发过程中，前后端的接口联调对接工作量占比在30%-50%左右，甚至会更高。往往前后端接口联调对接及系统间的联调对接都是整个产品项目研发的软肋。

本文的主要初衷就是规范约定先行，尽量避免沟通联调产生的不必要的问题，让大家身心愉快地专注于各自擅长的领域。

2. 为何要分离

目前现有前后端开发模式：“后端为主的MVC时代”，如下图所示：

后端为主的MVC时代

代码可维护性得到明显好转，MVC 是个非常好的协作模式，从架构层面让开发者懂得什么代码应该写在什么地方。为了让 View 层更简单干脆，还可以选择 Velocity、Freemaker 等模板，使得模板里写不了 Java 代码。看起来是功能变弱了，但正是这种限制使得前后端分工更清晰。然而依旧并不是那么清晰，这个阶段的典型问题是：

综上所述，就跟為什麼要代碼重構一樣：

3. 什么是分离

我们现在要做的前后分离第一阶段：“基于 Ajax 带来的 SPA 时代”，如图：

基于 Ajax 带来的 SPA 时代

这种模式下，前后端的分工非常清晰，前后端的关键协作点是 Ajax 接口。看起来是如此美妙，但回过头来看看的话，这与 JSP 时代区别不大。复杂度从服务端的 JSP 里移到了浏览器的 JavaScript，浏览器端变得很复杂。类似 Spring MVC，这个时代开始出现浏览器端的分层架构：[[271096]]

浏览器端的分层架构

对于这一SPA阶段，前后端分离有几个重要挑战：

4. 如何做分离

4.1 职责分离

职责分离

后端前端提供数据接收数据，返回数据处理业务逻辑处理渲染逻辑Server-side MVC架构Client-side MV* 架构代码跑在服务器上代码跑在浏览器上

4.2 开发流程

Mock 服务器根据接口文档自动生成 Mock 数据，实现了接口文档即API：

开发流程

4.3 具体实施

现在已基本完成了，接口方面的实施：

接口文档服务器：可实现接口变更实时同步给前端展示;

Mock接口数据平台：可实现接口变更实时Mock数据给前端使用;

接口规范定义：很重要，接口定义的好坏直接影响到前端的工作量和实现逻辑;具体定义规范见下节;

接口文档+Mock平台服务器

5. 接口规范V1.0.0

5.1 规范原则

接口返回数据即显示：前端仅做渲染逻辑处理;

渲染逻辑禁止跨多个接口调用;

前端关注交互、渲染逻辑，尽量避免业务逻辑处理的出现;

请求响应传输数据格式：JSON，JSON数据尽量简单轻量，避免多级JSON的出现;

5.2 基本格式

5.2.1 请求基本格式

GET请求、POST请求==必须包含key为body的入参，所有请求数据包装为JSON格式，并存放到入参body中==，示例如下：

1.GET请求：

 
 
 
 
    
  
  
  
  
  1. xxx/login?body={"username":"admin","password":"123456","captcha":"scfd","rememberMe":1} 
    2.

2.POST请求：

POST请求

5.2.2 响应基本格式

 
 
 
 
    
  
  
  
  
  1. { 
    2.   
  
  
  
  2.  code: 200, 
    3.   
  
  
  
  3.  data: { 
    4.   
  
  
  
  4.  message: "success" 
    5.   
  
  
  
  5.  } 
    6.   
  
  
  
  6. } 
    7.

1.code : 请求处理状态

 
 
 
 
    
  
  
  
  
  1. 200: 请求处理成功 500: 请求处理失败 401: 请求未认证，跳转登录页 406: 请求未授权，跳转未授权提示页 
    2.

2.data.message: 请求处理消息

 
 
 
 
    
  
  
  
  
  1. code=200 且 data.message="success": 请求处理成功 code=200 且 data.message!="success": 请求处理成功, 普通消息提示：message内容 code=500: 请求处理失败，警告消息提示：message内容 
    2.

5.3 响应实体格式

 
 
 
 
    
  
  
  
  
  1. { 
    2.   
  
  
  
  2.  code: 200, 
    3.   
  
  
  
  3.  data: { 
    4.   
  
  
  
  4.  message: "success", 
    5.   
  
  
  
  5.  entity: { 
    6.   
  
  
  
  6.  id: 1, 
    7.   
  
  
  
  7.  name: "XXX", 
    8.   
  
  
  
  8.  code: "XXX" 
    9.   
  
  
  
  9.  } 
    10.   
  
  
  
  10.  } 
    11.   
  
  
  
  11. } 
    12.

data.entity: 响应返回的实体数据

5.4 响应列表格式

 
 
 
 
    
  
  
  
  
  1. { 
    2.   
  
  
  
  2.  code: 200, 
    3.   
  
  
  
  3.  data: { 
    4.   
  
  
  
  4.  message: "success", 
    5.   
  
  
  
  5.  list: [ 
    6.   
  
  
  
  6.  { 
    7.   
  
  
  
  7.  id: 1, 
    8.   
  
  
  
  8.  name: "XXX", 
    9.   
  
  
  
  9.  code: "XXX" 
    10.   
  
  
  
  10.  }, 
    11.   
  
  
  
  11.  { 
    12.   
  
  
  
  12.  id: 2, 
    13.   
  
  
  
  13.  name: "XXX", 
    14.   
  
  
  
  14.  code: "XXX" 
    15.   
  
  
  
  15.  } 
    16.   
  
  
  
  16.  ] 
    17.   
  
  
  
  17.  } 
    18.   
  
  
  
  18. } 
    19.

data.list: 响应返回的列表数据

5.5 响应分页格式

 
 
 
 
    
  
  
  
  
  1. { 
    2.   
  
  
  
  2.  code: 200, 
    3.   
  
  
  
  3.  data: { 
    4.   
  
  
  
  4.  recordCount: 2, 
    5.   
  
  
  
  5.  message: "success", 
    6.   
  
  
  
  6.  totalCount: 2, 
    7.   
  
  
  
  7.  pageNo: 1, 
    8.   
  
  
  
  8.  pageSize: 10, 
    9.   
  
  
  
  9.  list: [ 
    10.   
  
  
  
  10.  { 
    11.   
  
  
  
  11.  id: 1, 
    12.   
  
  
  
  12.  name: "XXX", 
    13.   
  
  
  
  13.  code: "H001" 
    14.   
  
  
  
  14.  }, 
    15.   
  
  
  
  15.  { 
    16.   
  
  
  
  16.  id: 2, 
    17.   
  
  
  
  17.  name: "XXX", 
    18.   
  
  
  
  18.  code: "H001" 
    19.   
  
  
  
  19.  } ], 
    20.   
  
  
  
  20.  totalPage: 1 
    21.   
  
  
  
  21.  } 
    22.   
  
  
  
  22. } 
    23.

data.recordCount: 当前页记录数 data.totalCount: 总记录数 data.pageNo: 当前页码 data.pageSize: 每页大小 data.totalPage: 总页数

5.6 特殊内容规范

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

由后端接口统一逻辑判定是否选中，通过isSelect标示是否选中，示例如下：

 
 
 
 
    
  
  
  
  
  1. { 
    2.   
  
  
  
  2.  code: 200, 
    3.   
  
  
  
  3.  data: { 
    4.   
  
  
  
  4.  message: "success", 
    5.   
  
  
  
  5.  list: [{ 
    6.   
  
  
  
  6.  id: 1, 
    7.   
  
  
  
  7.  name: "XXX", 
    8.   
  
  
  
  8.  code: "XXX", 
    9.   
  
  
  
  9.  isSelect: 1 
    10.   
  
  
  
  10.  }, { 
    11.   
  
  
  
  11.  id: 1, 
    12.   
  
  
  
  12.  name: "XXX", 
    13.   
  
  
  
  13.  code: "XXX", 
    14.   
  
  
  
  14.  isSelect: 0 
    15.   
  
  
  
  15.  }] 
    16.   
  
  
  
  16.  } 
    17.   
  
  
  
  17. } 
    18.

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

5.6.2 Boolean类型

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

5.6.3 日期类型

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

6. 未来的大前端

目前我们现在用的前后端分离模式属于第一阶段，由于使用到的一些技术jquery等，对于一些页面展示、数据渲染还是比较复杂，不能够很好的达到复用。对于前端还是有很大的工作量。

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

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


本文标题：谈谈前后分离接口规范
标题路径：http://cdbrznjsb.com/article/cdcjgci.html

其他资讯

让你的专属顾问为你服务