首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >专栏 >聊聊前后端分离的接口规范

聊聊前后端分离的接口规范

作者头像
程序猿DD
发布于 2021-10-14 02:09:33
发布于 2021-10-14 02:09:33
86000
代码可运行
举报
文章被收录于专栏:程序猿DD程序猿DD
运行总次数:0
代码可运行
作者 | 猿码道

来源 | https://www.jianshu.com/p/c81008b68350

1. 前言

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

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

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

2. 为何要分离

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

后端为主的MVC时代

代码可维护性得到明显好转,MVC 是个非常好的协作模式,从架构层面让开发者懂得什么代码应该写在什么地方。为了让 View 层更简单干脆,还可以选择 Velocity、Freemaker 等模板,使得模板里写不了 Java 代码。

如果您正在学习Spring Boot,推荐一个连载多年还在继续更新的免费教程:http://blog.didispace.com/spring-boot-learning-2x/

看起来是功能变弱了,但正是这种限制使得前后端分工更清晰。然而依旧并不是那么清晰,这个阶段的典型问题是:

前端开发重度依赖开发环境,开发效率低。

这种架构下,前后端协作有两种模式:一种是前端写demo,写好后,让后端去套模板 。淘宝早期包括现在依旧有大量业务线是这种模式。好处很明显,demo 可以本地开发,很高效。不足是还需要后端套模板,有可能套错,套完后还需要前端确定,来回沟通调整的成本比较大。

另一种协作模式是前端负责浏览器端的所有开发和服务器端的 View 层模板开发,支付宝是这种模式。好处是 UI 相关的代码都是前端去写就好,后端不用太关注,不足就是前端开发重度绑定后端环境,环境成为影响前端开发效率的重要因素。

前后端职责依旧纠缠不清。

Velocity 模板还是蛮强大的,变量、逻辑、宏等特性,依旧可以通过拿到的上下文变量来实现各种业务逻辑。这样,只要前端弱势一点,往往就会被后端要求在模板层写出不少业务代码。还有一个很大的灰色地带是 Controller,页面路由等功能本应该是前端最关注的,但却是由后端来实现。Controller 本身与 Model 往往也会纠缠不清,看了让人咬牙的业务代码经常会出现在 Controller 层。这些问题不能全归结于程序员的素养,否则 JSP 就够了。

对前端发挥的局限。

性能优化如果只在前端做空间非常有限,于是我们经常需要后端合作才能碰撞出火花,但由于后端框架限制,我们很难使用Comet、Bigpipe等技术方案来优化性能。

总上所述,就跟为什麽要代码重构一样:

  • 关注点分离
  • 职责分离
  • 对的人做对的事
  • 更好的共建模式
  • 快速的反应变化

3. 什么是分离

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

基于 Ajax 带来的 SPA 时代

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

浏览器端的分层架构

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

前后端接口的约定。

如果后端的接口一塌糊涂,如果后端的业务模型不够稳定,那么前端开发会很痛苦。这一块在业界有 API Blueprint 等方案来约定和沉淀接口,==在阿里,不少团队也有类似尝试,通过接口规则、接口平台等方式来做。有了和后端一起沉淀的接口规则,还可以用来模拟数据,使得前后端可以在约定接口后实现高效并行开发。== 相信这一块会越做越好。

另外,如果您正在学习Spring Cloud,推荐一个连载多年还在继续更新的免费教程:https://blog.didispace.com/spring-cloud-learning/

前端开发的复杂度控制。

SPA 应用大多以功能交互型为主,JavaScript 代码过十万行很正常。大量 JS 代码的组织,与 View 层的绑定等,都不是容易的事情。典型的解决方案是业界的 Backbone,但 Backbone 做的事还很有限,依旧存在大量空白区域需要挑战。

4. 如何做分离

4.1 职责分离

职责分离

  • 前后端仅仅通过异步接口(AJAX/JSONP)来编程
  • 前后端都各自有自己的开发流程,构建工具,测试集合
  • 关注点分离,前后端变得相对独立并松耦合
4.2 开发流程
  • 后端编写和维护接口文档,在 API 变化时更新接口文档
  • 后端根据接口文档进行接口开发
  • 前端根据接口文档进行开发 + Mock平台
  • 开发完成后联调和提交测试
  • 如果您正在学习Spring Boot,推荐一个连载多年还在继续更新的免费教程:http://blog.didispace.com/spring-boot-learning-2x/

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中==,示例如下:

GET请求:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
xxx/login?body={"username":"admin","password":"123456","captcha":"scfd","rememberMe":1}

POST请求:

5.2.2 响应基本格式
代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
{
    code: 200,
    data: {
        message: "success"
    }
}

code : 请求处理状态

  • 200: 请求处理成功
  • 500: 请求处理失败
  • 401: 请求未认证,跳转登录页
  • 406: 请求未授权,跳转未授权提示页
  • 另外,如果您正在学习Spring Cloud,推荐一个连载多年还在继续更新的免费教程:https://blog.didispace.com/spring-cloud-learning/

data.message: 请求处理消息

  • code=200 且 data.message="success": 请求处理成功
  • code=200 且 data.message!="success": 请求处理成功, 普通消息提示:message内容
  • code=500: 请求处理失败,警告消息提示:message内容
5.3 响应实体格式
代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
{
    code: 200,
    data: {
        message: "success",
        entity: {
            id: 1,
            name: "XXX",
            code: "XXX"
        }
    }
}

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

5.4 响应列表格式

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

5.5 响应分页格式
代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
{
    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标示是否选中,示例如下:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
{
    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* 时代==”。大多数的公司也基本都处于这个分离阶段。

如果您正在学习Spring Boot,推荐一个连载多年还在继续更新的免费教程:http://blog.didispace.com/spring-boot-learning-2x/

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

这两个阶段仅做简单介绍,有兴趣的可以参考下面的资料。

7. 参考资料

https://www.zhihu.com/question/28207685 http://taobaofed.org/ http://2014.jsconf.cn/slides/herman-taobaoweb http://blog.jobbole.com/65509/ https://blog.kaolafed.com/ http://blog.jobbole.com/65513/ http://blog.jobbole.com/65534/ http://blog.jobbole.com/65541/ http://blog.jobbole.com/56161

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2021-10-08,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 程序猿DD 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
暂无评论
推荐阅读
编辑精选文章
换一批
聊聊前后端分离接口规范
随着互联网的高速发展,前端页面的展示、交互体验越来越灵活、炫丽,响应体验也要求越来越高,后端服务的高并发、高可用、高性能、高扩展等特性的要求也愈加苛刻,从而导致前后端研发各自专注于自己擅长的领域深耕细作。
用户1516716
2019/10/23
5440
聊聊前后端分离接口规范
聊聊前后端分离接口规范
随着互联网的高速发展,前端页面的展示、交互体验越来越灵活、炫丽,响应体验也要求越来越高,后端服务的高并发、高可用、高性能、高扩展等特性的要求也愈加苛刻,从而导致前后端研发各自专注于自己擅长的领域深耕细作。
芋道源码
2019/06/15
8150
前后端分离的接口规范
点击上方“芋道源码”,选择“设为星标” 管她前浪,还是后浪? 能浪的浪,才是好浪! 每天 10:33 更新文章,每天掉亿点点头发... 源码精品专栏 原创 | Java 2021 超神之路,很肝~ 中文详细注释的开源项目 RPC 框架 Dubbo 源码解析 网络应用框架 Netty 源码解析 消息中间件 RocketMQ 源码解析 数据库中间件 Sharding-JDBC 和 MyCAT 源码解析 作业调度中间件 Elastic-Job 源码解析 分布式事务中间件 TCC-Transaction
芋道源码
2022/03/24
6590
前后端分离必备的接口规范,十分接地气!
随着互联网的高速发展,前端页面的展示、交互体验越来越灵活、炫丽,响应体验也要求越来越高,后端服务的高并发、高可用、高性能、高扩展等特性的要求也愈加苛刻,从而导致前后端研发各自专注于自己擅长的领域深耕细作。
Java技术栈
2019/07/23
2K0
架构:前后端分离的必要性及接口规范
随着互联网的高速发展,前端页面的展示、交互体验越来越灵活、炫丽,响应体验也要求越来越高,后端服务的高并发、高可用、高性能、高扩展等特性的要求也愈加苛刻,从而导致前后端研发各自专注于自己擅长的领域深耕细作。
Freedom123
2024/03/29
3730
架构:前后端分离的必要性及接口规范
浅谈前后端分离(下篇)
上篇主要介绍一下前后端分离的一些优缺点,本篇主要介绍一下前后端分离的一些落地,不过在介绍之前,要先阐述一下在实施前后端分离时,要考虑到一些东西
lyb-geek
2022/03/10
1.3K0
浅谈前后端分离(下篇)
可能是最好的跨域解决方案了
作者 | campcc 来源 | https://github.com/campcc/blog 今天我们来聊一个老生常谈的话题,跨域!又是跨域,烦不烦 ?网上跨域的文章那么多,跨的我眼睛都疲劳了,不看了不看了 🤣 别走...我尽量用最简单的方式将常见的几种跨域解决方案给大家阐释清楚,相信认真看完本文,以后不管是作为受试者还是面试官,对于这块的知识都能够游刃有余。 什么是“跨源” 不是讲跨域吗 ?怎么又来个“跨源” ?字都能打错的 ?😄...稍安勿躁,其实我们平常说的跨域是一种狭义的请求场景,简单来说,就是
JAVA葵花宝典
2021/11/23
5200
前后端不分离到分离演变,优势,前后端接口联调,排错及优化
 核心思想是前端html页面通过ajax调用后端的restuful api接口并使用json数据进行交互。
iginkgo18
2020/12/07
2.8K0
前后端不分离到分离演变,优势,前后端接口联调,排错及优化
实用!前后端分离开发之前端模拟数据
前后端分离的架构中,前后端同学约定好接口后就可以并行开发,最后双方再进行接口的联调。不过实际开发时,前后端联调会遇到下面这些问题,这些问题无疑中会影响联调的效率,拉长整个开发的周期。
前端林子
2019/08/25
6.6K2
实用!前后端分离开发之前端模拟数据
前后端分离:现代Web开发的最佳实践
前后端分离开发 是一种将Web开发中的前端(UI展示层)和后端(业务逻辑层)完全分离开来的开发模式。传统的Web开发中,前后端代码通常紧密耦合在一起,前端通过页面渲染直接调用后端的业务逻辑。而在前后端分离的模式下,前端和后端通过明确的API接口进行通信,独立开发、独立部署和独立运行。
Lntano
2025/01/20
7290
前后端分离-搭建本地 mock 服务
搭建本地 mock 服务器 ---为了更好的前端开发 工作中,有时候前端的很多工作需要后端的支持,但是可能后端的接口还没有开发完,或者有些时候在联调阶段,修复某个 bug 的时候,环境挂了。。。 那么这个时候,我们的很多工作无法顺利的进行下去。于是萌生了搭建本地服务器的想法。 首先粗略的说一下它的好处 前端更加独立,在开发阶段对于后端的依赖性大大降低。 联调和开发截断,对于新增加的接口,只需要后端提供接口文档就好,不需要等到他们真正的开发完成,前端就可以自己进入联调。 修复和定位 bug 更加便捷,自
念念不忘
2019/03/29
3K0
前后端分离-搭建本地 mock 服务
聊聊事件驱动的架构模式
作者 | Natan Silnitsky 来源 | Wix 工程博客 最近经常听到谁谁谁用事件驱动了,正好看到一篇不错的关于事件架构的文章,分享给你,希望对你有帮助,以下是正文。 在过去一年里,我一直是数据流团队的一员,负责Wix事件驱动的消息传递基础设施(基于 Kafka)。有超过 1400 个微服务使用这个基础设施。在此期间,我实现或目睹了事件驱动消息传递设计的几个关键模式,这些模式有助于创建一个健壮的分布式系统,该系统可以轻松地处理不断增长的流量和存储需求。 1.消费与投影 针对那些使用非常广泛、已
程序猿DD
2023/04/04
1.8K0
聊聊事件驱动的架构模式
为什么前后端分离了,你比从前更痛苦?
来源:https://my.oschina.net/xbl/blog/2246297
程序猿DD
2018/12/18
5570
为什么前后端分离了,你比从前更痛苦?
再谈前后端分离
前言 前后端分离已经是业界所共识的一种开发/部署模式了。所谓的前后端分离,并不是传统行业中的按部门划分,一部分人纯做前端(HTML/CSS/JavaScript/Flex),另一部分人纯做后端,因为这种方式是不工作的:比如很多团队采取了后端的模板技术(JSP, FreeMarker, ERB等等),前端的开发和调试需要一个后台Web容器的支持,从而无法做到真正的分离(更不用提在部署的时候,由于动态内容和静态内容混在一起,当设计动态静态分流的时候,处理起来非常麻烦)。关于前后端开发的另一个讨论可以参考这里。
前朝楚水
2018/04/03
1.3K0
再谈前后端分离
Spring Boot 2.x基础教程:多文件的上传
昨天,我们介绍了如何在Spring Boot中实现文件的上传(博客地址:https://blog.didispace.com/spring-boot-learning-21-4-3/)。有读者问:那么如果有多个文件要同时上传呢?这就马上奉上,当碰到多个文件要同时上传时候的处理方法。
程序猿DD
2021/01/12
5440
Spring Boot 2.x基础教程:多文件的上传
前后端分离
传统的Java Web开发中,前端使用JSP开发,JSP不是由后端开发者来独立完成的。
Tanger
2021/12/26
6320
Spring Security + JWT实现前后端分离权限认证
现在国内前后端很多公司都在使用前后端分离的开发方式,虽然也有很多人并不赞同前后端分离,比如以下这篇博客就很有意思:
二十三年蝉
2018/08/27
1.5K0
前后端分离时代,Java 程序员的变与不变!
松哥认真看了下这个问题,感觉对于初次接触前后端分离的小伙伴来说,可能都会存在这样的疑问,于是决定通过这篇文章和大家聊一聊这个话题。
江南一点雨
2019/07/10
5530
某神秘公司 RESTful、共用接口、前后端分离、接口约定的实践
https://juejin.im/post/59eafab36fb9a045076eccc3
良月柒
2019/03/20
8760
某神秘公司 RESTful、共用接口、前后端分离、接口约定的实践
前后端分离的接口设计规范
RESTful API设计风格:RESTful API是一种基于HTTP协议的API设计风格,它包括使用HTTP动词(GET、POST、PUT、DELETE等)来表示对资源的操作,使用URI来表示资源的路径,使用HTTP状态码来表示请求的结果等。这种设计风格可以使接口设计更加简洁明了。
IT从业者张某某
2023/10/16
4880
推荐阅读
相关推荐
聊聊前后端分离接口规范
更多 >
交个朋友
加入腾讯云官网粉丝站
蹲全网底价单品 享第一手活动信息
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档