前端规范——前后端接口规范
通用要求
接口命名小駝峰
如果不是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 字段返回需要完整,禁止字段返回缺失
例如
message
如果code返回不是200,則前端彈窗提示message,需要簡單醒目,不能拋出 Java的堆棧報錯信息
如果code返回正確,message也盡量返回正確信息,用于前后端對比
前端通用組件要求
前端基于目前的業務,封裝了一些公用列表、彈窗、交互、數據脫敏等一系列通用組件,需要后端的同一類接口,進行method、請求格式、返回格式的統一
例如:
- 獲取列表的接口,post方式
- 通過id獲取單個數據項的信息時,使用restfull的get格式,如 /person/123
- 添加類接口,post方式;更新類接口,put方式;刪除類接口,delete方式
列表分頁請求,通用參數
page: 當前頁碼,以1開始
size:當前頁面展示的條數,前端默認10
總之,不能出現分頁信息,傳入后端需要的start+limit的那種數據庫查詢的方式
列表返回的格式
需要返回 total 總條數,前端用于分頁
不需要返回總頁數之類的信息
日期格式傳輸
前后端傳輸時間字段,均以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: 1label: '已創建'}, {value: 2label: '部分完成'}],"message":"成功" // 提示信息,如果code不是200的話,前端將此提示信息彈窗展示 }后發先至接口的處理
有的時候,接口調用比較密集,而前端拿到返回需要有次序,此時需要后端在返回體內,添加前端開始調用接口的時間戳,用于前端來判斷接口前后順序
總結
以上是生活随笔為你收集整理的前端规范——前后端接口规范的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: ubuntu安装jdk出现的问题Fail
- 下一篇: WinRAR 4.00 beta1 简体