前端规范——前后端接口规范

通用要求

接口命名小驼峰
如果不是restfull的接口,需要语义化,例如:getUserInfo、getUserList、createUser、updateUser、deleteUser、uploadUserImg
接口尽量轻巧,前端不需要的数据,不需要返回
后端尽量统一风格,禁止单独适配
为了避免某些Chrome浏览器广告屏蔽插件的误拦截,不使用ad等广告字眼

对前端的要求:前端使用axios统一封装请求方法,做统一请求、拦截

安全性要求

如果是客户敏感信息,接口绝对需要返回最小量的数据
需要进行数据脱敏的情况,由后端进行脱敏,不能仅靠前端来脱敏展示
提交订单类接口,后端不能相信前端传入的金额数据,需要自己计算

接口的部署

接口统一部署在网关上,相关后端同学来维护发布

接口文档维护

统一维护在yapi平台上,禁止其余方式传输,一切以yapi平台为准;接口的变更,也需要同步在yapi平台上
接口文档,字段需要有必要的中文描述,以及枚举值

通用接口返回体

{
    "code":"200", // 状态码,200-正常;401-未登录,前端控制跳转登录界面
    "data":{ // 数据返回体
         
    },
    "message":"成功" // 提示信息,如果code不是200的话,前端将此提示信息弹窗展示
}

code枚举
200:正常
401:未登录,前端控制跳转登录界面
403:无权限,前端跳转相应界面

data 字段返回需要完整,禁止字段返回缺失
例如

data: {
	name: '', // 空字符串
	obj: null, // 空对象
	totol: 0, // 无值的数字
	list: [] // 空数组
}

message
如果code返回不是200,则前端弹窗提示message,需要简单醒目,不能抛出 Java的堆栈报错信息
如果code返回正确,message也尽量返回正确信息,用于前后端对比

前端通用组件要求

前端基于目前的业务,封装了一些公用列表、弹窗、交互、数据脱敏等一系列通用组件,需要后端的同一类接口,进行method、请求格式、返回格式的统一

例如:

  • 获取列表的接口,post方式
  • 通过id获取单个数据项的信息时,使用restfull的get格式,如 /person/123
  • 添加类接口,post方式;更新类接口,put方式;删除类接口,delete方式

列表分页请求,通用参数

page: 当前页码,以1开始
size:当前页面展示的条数,前端默认10

总之,不能出现分页信息,传入后端需要的start+limit的那种数据库查询的方式

列表返回的格式

需要返回 total 总条数,前端用于分页
不需要返回总页数之类的信息

{
    "code":"200", // 状态码
    "data":{
        "records":[ // 数据list
 
        ],
        "total":20 // 总条数
    },
    "message":"成功" // 提示信息,如果code不是200的话,前端将此提示信息弹窗展示
}

日期格式传输

前后端传输时间字段,均以13位标准时间戳传输

布尔类数据

统一使用1、0来传输数据,1为true,0为false

超长型数字

后端库表的id,可能生成时超过16位,此时会面临精度丢失问题,这种情况,需要将id,通过字符串的形式传回到前端

数据精度处理

为了避免出现那种0.1+0.2=0.30000000000000004的问题,通常情况下,前端不做计算后结果的传输,一切计算后的数据,均由后端来计算
电商订单类,更应当如此!!!
后端返回前端数据,数据精度也需要过滤校验

图片地址的返回

需要返回全量的oss图片地址,禁止前端拿到url后再行拼接https

post方式请求细节

Content-Type的选择
除了上传类的post请求使用multipart/form-data外,其余的post请求,均使用application/json格式

post方式,尽量避免通过url上传值,统一放在body里面

模糊搜索接口约定

模糊搜索,要求速度快,数据量少

   请求方式:get

   接口返回:无需分页,最多返回10条数据

如无特殊规定,模糊搜索接口返回数组格式,格式如下

{
    "code":"200", // 状态码
    "data": [{
        value: 1
        label: '已创建'
    }, {
        value: 2
        label: '部分完成'
    }],
    "message":"成功" // 提示信息,如果code不是200的话,前端将此提示信息弹窗展示
}

后发先至接口的处理

有的时候,接口调用比较密集,而前端拿到返回需要有次序,此时需要后端在返回体内,添加前端开始调用接口的时间戳,用于前端来判断接口前后顺序

  • 4
    点赞
  • 19
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
项目系统结构——前后端分离是一种常见的Web应用程序开发模式,它采用了一种分离前端和后端的策略,将应用程序分为两个独立的部分:前端和后端。这种模式通常用于构建复杂的应用程序,如企业级管理系统、在线购物平台等。 以下是项目系统结构——前后端分离的主要组成部分: 前端: 1. 客户端应用程序:通常使用JavaScript框架(如React、Vue、Angular等)或前端Web框架(如Django、Flask等)开发,用于处理用户界面、数据请求和响应等功能。 2. 静态资源:包括CSS、图片、JavaScript等静态资源文件,通常存储在Web服务器上,供前端应用程序使用。 后端: 1. API服务:提供RESTful或GraphQL风格的API接口,用于处理业务逻辑和数据操作。后端服务通常使用服务器端语言(如Python、Java、Node.js等)编写,并使用数据库存储数据。 2. 数据库:用于存储和管理应用程序的数据,通常使用关系型数据库(如MySQL、PostgreSQL等)或非关系型数据库(如MongoDB、Redis等)。 前后端分离的优点: 1. 开发效率高:前端和后端可以由不同的团队或个人独立开发,减少了沟通和协作的难度。 2. 可扩展性好:前后端分离的应用程序可以根据需要灵活地添加新的前端或后端组件,提高了系统的可扩展性。 3. 灵活性高:前端可以使用不同的技术栈,如移动端应用程序、小程序等,提高了应用的灵活性。 前后端分离的缺点: 1. 安全性问题:前后端分离的应用程序可能存在安全风险,如跨站脚本攻击(XSS)和SQL注入等。因此,需要采取适当的措施来保护应用程序的安全性。 2. 集成问题:前后端分离的应用程序需要将数据从后端传输到前端,需要处理数据格式转换、数据验证等问题。 3. 调试和测试难度大:前后端分离的应用程序需要分别进行调试和测试,增加了开发和测试的难度。 总之,项目系统结构——前后端分离是一种灵活、可扩展的开发模式,适用于构建复杂的应用程序。在开发过程中,需要关注安全性和集成问题,并采取适当的措施来确保应用程序的稳定性和可靠性。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值