咨詢(xún)電話(huà)
微信掃一掃
新聞動(dòng)態(tài)
聊聊前后端分離接口規范
常見(jiàn)問(wèn)題 發(fā)布者:cya 2019-11-27 08:40 訪(fǎng)問(wèn)量:87
作者:猿碼道
鏈接:https://www.jianshu.com/p/c81008b68350
閱讀本文需要5分鐘
隨著(zhù)互聯(lián)網(wǎng)的高速發(fā)展,前端頁(yè)面的展示、交互體驗越來(lái)越靈活、炫麗,響應體驗也要求越來(lái)越高,后端服務(wù)的高并發(fā)、高可用、高性能、高擴展等特性的要求也愈加苛刻,從而導致前后端研發(fā)各自專(zhuān)注于自己擅長(cháng)的領(lǐng)域深耕細作。
然而帶來(lái)的另一個(gè)問(wèn)題:前后端的對接界面雙方卻關(guān)注甚少,沒(méi)有任何接口約定規范情況下各自干各自的,導致我們在產(chǎn)品項目開(kāi)發(fā)過(guò)程中,前后端的接口聯(lián)調對接工作量占比在30%-50%左右,甚至會(huì )更高。往往前后端接口聯(lián)調對接及系統間的聯(lián)調對接都是整個(gè)產(chǎn)品項目研發(fā)的軟肋。
本文的主要初衷就是規范約定先行,盡量避免溝通聯(lián)調產(chǎn)生的不必要的問(wèn)題,讓大家身心愉快地專(zhuān)注于各自擅長(cháng)的領(lǐng)域。
參考兩篇文章:
http://blog.jobbole.com/65509/
http://blog.jobbole.com/56161/
目前現有前后端開(kāi)發(fā)模式:“后端為主的MVC時(shí)代”,如下圖所示:
后端為主的MVC時(shí)代
代碼可維護性得到明顯好轉,MVC 是個(gè)非常好的協(xié)作模式,從架構層面讓開(kāi)發(fā)者懂得什么代碼應該寫(xiě)在什么地方。為了讓 View 層更簡(jiǎn)單干脆,還可以選擇 Velocity、Freemaker 等模板,使得模板里寫(xiě)不了 Java 代碼。
看起來(lái)是功能變弱了,但正是這種限制使得前后端分工更清晰。然而依舊并不是那么清晰,這個(gè)階段的典型問(wèn)題是:
前端開(kāi)發(fā)重度依賴(lài)開(kāi)發(fā)環(huán)境,開(kāi)發(fā)效率低。
這種架構下,前后端協(xié)作有兩種模式:一種是前端寫(xiě)demo,寫(xiě)好后,讓后端去套模板 。淘寶早期包括現在依舊有大量業(yè)務(wù)線(xiàn)是這種模式。好處很明顯,demo 可以本地開(kāi)發(fā),很高效。不足是還需要后端套模板,有可能套錯,套完后還需要前端確定,來(lái)回溝通調整的成本比較大。
另一種協(xié)作模式是前端負責瀏覽器端的所有開(kāi)發(fā)和服務(wù)器端的 View 層模板開(kāi)發(fā),支付寶是這種模式。好處是 UI 相關(guān)的代碼都是前端去寫(xiě)就好,后端不用太關(guān)注,不足就是前端開(kāi)發(fā)重度綁定后端環(huán)境,環(huán)境成為影響前端開(kāi)發(fā)效率的重要因素。
前后端職責依舊糾纏不清。
Velocity 模板還是蠻強大的,變量、邏輯、宏等特性,依舊可以通過(guò)拿到的上下文變量來(lái)實(shí)現各種業(yè)務(wù)邏輯。這樣,只要前端弱勢一點(diǎn),往往就會(huì )被后端要求在模板層寫(xiě)出不少業(yè)務(wù)代碼。還有一個(gè)很大的灰色地帶是 Controller,頁(yè)面路由等功能本應該是前端最關(guān)注的,但卻是由后端來(lái)實(shí)現。Controller 本身與 Model 往往也會(huì )糾纏不清,看了讓人咬牙的業(yè)務(wù)代碼經(jīng)常會(huì )出現在 Controller 層。這些問(wèn)題不能全歸結于程序員的素養,否則 JSP 就夠了。
對前端發(fā)揮的局限。
性能優(yōu)化如果只在前端做空間非常有限,于是我們經(jīng)常需要后端合作才能碰撞出火花,但由于后端框架限制,我們很難使用Comet、Bigpipe等技術(shù)方案來(lái)優(yōu)化性能。
總上所述,就跟為什麼要代碼重構一樣:
關(guān)注點(diǎn)分離
職責分離
對的人做對的事
更好的共建模式
快速的反應變化
我們現在要做的前后分離第一階段:“基于 Ajax 帶來(lái)的 SPA 時(shí)代”,如圖:
基于 Ajax 帶來(lái)的 SPA 時(shí)代
這種模式下,前后端的分工非常清晰,前后端的關(guān)鍵協(xié)作點(diǎn)是 Ajax 接口??雌饋?lái)是如此美妙,但回過(guò)頭來(lái)看看的話(huà),這與 JSP 時(shí)代區別不大。復雜度從服務(wù)端的 JSP 里移到了瀏覽器的 JavaScript,瀏覽器端變得很復雜。類(lèi)似 Spring MVC,這個(gè)時(shí)代開(kāi)始出現瀏覽器端的分層架構:
瀏覽器端的分層架構
對于這一SPA階段,前后端分離有幾個(gè)重要挑戰:
前后端接口的約定。
如果后端的接口一塌糊涂,如果后端的業(yè)務(wù)模型不夠穩定,那么前端開(kāi)發(fā)會(huì )很痛苦。這一塊在業(yè)界有 API Blueprint 等方案來(lái)約定和沉淀接口,==在阿里,不少團隊也有類(lèi)似嘗試,通過(guò)接口規則、接口平臺等方式來(lái)做。有了和后端一起沉淀的接口規則,還可以用來(lái)模擬數據,使得前后端可以在約定接口后實(shí)現高效并行開(kāi)發(fā)。== 相信這一塊會(huì )越做越好。
前端開(kāi)發(fā)的復雜度控制。
SPA 應用大多以功能交互型為主,JavaScript 代碼過(guò)十萬(wàn)行很正常。大量 JS 代碼的組織,與 View 層的綁定等,都不是容易的事情。典型的解決方案是業(yè)界的 Backbone,但 Backbone 做的事還很有限,依舊存在大量空白區域需要挑戰。
職責分離
前后端僅僅通過(guò)異步接口(AJAX/JSONP)來(lái)編程
前后端都各自有自己的開(kāi)發(fā)流程,構建工具,測試集合
關(guān)注點(diǎn)分離,前后端變得相對獨立并松耦合
后端編寫(xiě)和維護接口文檔,在 API 變化時(shí)更新接口文檔
后端根據接口文檔進(jìn)行接口開(kāi)發(fā)
前端根據接口文檔進(jìn)行開(kāi)發(fā) + Mock平臺
開(kāi)發(fā)完成后聯(lián)調和提交測試
Mock 服務(wù)器根據接口文檔自動(dòng)生成 Mock 數據,實(shí)現了接口文檔即API:
開(kāi)發(fā)流程
現在已基本完成了,接口方面的實(shí)施:
接口文檔服務(wù)器:可實(shí)現接口變更實(shí)時(shí)同步給前端展示;
Mock接口數據平臺:可實(shí)現接口變更實(shí)時(shí)Mock數據給前端使用;
接口規范定義:很重要,接口定義的好壞直接影響到前端的工作量和實(shí)現邏輯;具體定義規范見(jiàn)下節;
接口文檔+Mock平臺服務(wù)器
接口返回數據即顯示:前端僅做渲染邏輯處理;
渲染邏輯禁止跨多個(gè)接口調用;
前端關(guān)注交互、渲染邏輯,盡量避免業(yè)務(wù)邏輯處理的出現;
請求響應傳輸數據格式:JSON,JSON數據盡量簡(jiǎn)單輕量,避免多級JSON的出現;
GET請求、POST請求==必須包含key為body的入參,所有請求數據包裝為JSON格式,并存放到入參body中==,示例如下:
GET請求:
xxx/login?body={"username":"admin","password":"123456","captcha":"scfd","rememberMe":1}
POST請求:
{
code: 200,
data: {
message: "success"
}
}
code : 請求處理狀態(tài)
200: 請求處理成功
500: 請求處理失敗
401: 請求未認證,跳轉登錄頁(yè)
406: 請求未授權,跳轉未授權提示頁(yè)
data.message: 請求處理消息
code=200 且 data.message="success": 請求處理成功
code=200 且 data.message!="success": 請求處理成功, 普通消息提示:message內容
code=500: 請求處理失敗,警告消息提示:message內容
{
code: 200,
data: {
message: "success",
entity: {
id: 1,
name: "XXX",
code: "XXX"
}
}
}
data.entity: 響應返回的實(shí)體數據
data.list: 響應返回的列表數據
{
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: 當前頁(yè)記錄數
data.totalCount: 總記錄數
data.pageNo: 當前頁(yè)碼
data.pageSize: 每頁(yè)大小
data.totalPage: 總頁(yè)數
由后端接口統一邏輯判定是否選中,通過(guò)isSelect標示是否選中,示例如下:
{
code: 200,
data: {
message: "success",
list: [{
id: 1,
name: "XXX",
code: "XXX",
isSelect: 1
}, {
id: 1,
name: "XXX",
code: "XXX",
isSelect: 0
}]
}
}
禁止下拉框、復選框、單選框判定選中邏輯由前端來(lái)處理,統一由后端邏輯判定選中返回給前端展示;
關(guān)于Boolean類(lèi)型,JSON數據傳輸中一律使用1/0來(lái)標示,1為是/True,0為否/False;
關(guān)于日期類(lèi)型,JSON數據傳輸中一律使用字符串,具體日期格式因業(yè)務(wù)而定;
目前我們現在用的前后端分離模式屬于第一階段,由于使用到的一些技術(shù)jquery等,對于一些頁(yè)面展示、數據渲染還是比較復雜,不能夠很好的達到復用。對于前端還是有很大的工作量。
下一階段可以在前端工程化方面,對技術(shù)框架的選擇、前端模塊化重用方面,可多做考量。也就是要迎來(lái)“==前端為主的 MV* 時(shí)代==”。大多數的公司也基本都處于這個(gè)分離階段。
最后階段就是==Node 帶來(lái)的全棧時(shí)代==,完全有前端來(lái)控制頁(yè)面,URL,Controller,路由等,后端的應用就逐步弱化為真正的數據服務(wù)+業(yè)務(wù)服務(wù),做且僅能做的是提供數據、處理業(yè)務(wù)邏輯,關(guān)注高可用、高并發(fā)等。
這兩個(gè)階段僅做簡(jiǎn)單介紹,有興趣的可以參考下面的資料。
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/
關(guān)鍵字: 前后端分離 晨展科技 開(kāi)封網(wǎng)站建設
文章連接: http://www.gostscript.com/cjwt/619.html
版權聲明:文章由 晨展科技 整理收集,來(lái)源于互聯(lián)網(wǎng)或者用戶(hù)投稿,如有侵權,請聯(lián)系我們,我們會(huì )立即刪除。如轉載請保留
晨展解決方案
晨展新聞