1. 前言
创新互联技术团队10多年来致力于为客户提供成都网站设计、成都网站建设、品牌网站设计、营销型网站建设、搜索引擎SEO优化等服务。经过多年发展,公司拥有经验丰富的技术团队,先后服务、推广了近1000家网站,包括各类中小企业、企事单位、高校等机构单位。
随着互联网的高速发展,前端页面的展示、交互体验越来越灵活、炫丽,响应体验也要求越来越高,后端服务的高并发、高可用、高性能、高扩展等特性的要求也愈加苛刻,从而导致前后端研发各自专注于自己擅长的领域深耕细作。
然而带来的另一个问题:前后端的对接界面双方却关注甚少,没有任何接口约定规范情况下各自撸起袖子就是干,导致我们在产品项目开发过程中,前后端的接口联调对接工作量占比在30%-50%左右,甚至会更高。往往前后端接口联调对接及系统间的联调对接都是整个产品项目研发的软肋。
本文的主要初衷就是规范约定先行,尽量避免沟通联调产生的不必要的问题,让大家身心愉快地专注于各自擅长的领域。
2. 为何要分离
目前现有前后端开发模式:“后端为主的MVC时代”,如下图所示:
后端为主的MVC时代
代码可维护性得到明显好转,MVC 是个非常好的协作模式,从架构层面让开发者懂得什么代码应该写在什么地方。为了让 View 层更简单干脆,还可以选择 Velocity、Freemaker 等模板,使得模板里写不了 Java 代码。看起来是功能变弱了,但正是这种限制使得前后端分工更清晰。然而依旧并不是那么清晰,这个阶段的典型问题是:
总上所述,就跟为什么要代碼重構一样:
3. 什么是分离
我们现在要做的前后分离第一阶段:“基于 Ajax 带来的 SPA 时代”,如图:
基于 Ajax 带来的 SPA 时代
这种模式下,前后端的分工非常清晰,前后端的关键协作点是 Ajax 接口。 看起来是如此美妙,但回过头来看看的话,这与 JSP 时代区别不大。复杂度从服务端的 JSP 里移到了浏览器的 JavaScript,浏览器端变得很复杂。类似 Spring MVC,这个时代开始出现浏览器端的分层架构:
浏览器端的分层架构
对于这一SPA阶段,前后端分离有几个重要挑战:
4. 如何做分离
4.1 职责分离
职责分离
4.2 开发流程
Mock 服务器根据接口文档自动生成 Mock 数据,实现了接口文档即API:
开发流程
4.3 具体实施
现在已基本完成了,接口方面的实施:
接口文档+Mock平台服务器
5. 接口规范V1.0.0
5.1 规范原则
5.2 基本格式
5.2.1 请求基本格式
GET请求、POST请求==必须包含key为body的入参,所有请求数据包装为JSON格式,并存放到入参body中==,示例如下:
- xxx/login?body={"username":"admin","password":"123456","captcha":"scfd","rememberMe":1}
5.2.2 响应基本格式
- { code: 200,
- data: {
- message: "success"
- }
- }
(1) code : 请求处理状态
- 200: 请求处理成功
- 500: 请求处理失败
- 401: 请求未认证,跳转登录页
- 406: 请求未授权,跳转未授权提示页
(2) 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数据传输中一律使用字符串,具体日期格式因业务而定;
6. 未来的大前端
目前我们现在用的前后端分离模式属于第一阶段,由于使用到的一些技术jquery等,对于一些页面展示、数据渲染还是比较复杂,不能够很好的达到复用。对于前端还是有很大的工作量。
下一阶段可以在前端工程化方面,对技术框架的选择、前端模块化重用方面,可多做考量。也就是要迎来“==前端为主的 MV* 时代==”。 大多数的公司也基本都处于这个分离阶段。
最后阶段就是==Node 带来的全栈时代==,完全有前端来控制页面,URL,Controller,路由等,后端的应用就逐步弱化为真正的数据服务+业务服务,做且仅能做的是提供数据、处理业务逻辑,关注高可用、高并发等。
【本文为专栏作者“谢军”的原创稿件,转载可通过作者微信公众号(jingfeng18)获取联系】
戳这里,看该作者更多好文
新闻标题:掌握前后分离接口规范,减少不必要的沟通麻烦
本文URL:http://www.shufengxianlan.com/qtweb/news14/515764.html
成都网站建设公司_创新互联,为您提供网站维护、网站设计、面包屑导航、网页设计公司、网站设计公司、响应式网站
声明:本网站发布的内容(图片、视频和文字)以用户投稿、用户转载内容为主,如果涉及侵权请尽快告知,我们将会在第一时间删除。文章观点不代表本网站立场,如需处理请联系客服。电话:028-86922220;邮箱:631063699@qq.com。内容未经允许不得转载,或转载时需注明来源: 创新互联