隨著互聯(lián)網(wǎng)的高速發(fā)展,前端頁面的展示、交互體驗越來越靈活、炫麗,響應體驗也要求越來越高,后端服務的高并發(fā)、高可用、高性能、高擴展等特性的要求也愈加苛刻,從而導致前后端研發(fā)各自專注于自己擅長的領(lǐng)域深耕細作。
我們提供的服務有:做網(wǎng)站、網(wǎng)站制作、微信公眾號開發(fā)、網(wǎng)站優(yōu)化、網(wǎng)站認證、辰溪ssl等。為超過千家企事業(yè)單位解決了網(wǎng)站和推廣的問題。提供周到的售前咨詢和貼心的售后服務,是有科學管理、有技術(shù)的辰溪網(wǎng)站制作公司然而帶來的另一個問題:前后端的對接界面雙方卻關(guān)注甚少,沒有任何接口約定規(guī)范情況下各自擼起袖子就是干,導致我們在產(chǎn)品項目開發(fā)過程中,前后端的接口聯(lián)調(diào)對接
工作量占比在30%-50%左右,甚至會更高。往往前后端接口聯(lián)調(diào)對接及系統(tǒng)間的聯(lián)調(diào)對接都是整個產(chǎn)品項目研發(fā)的軟肋。
本文的主要初衷就是規(guī)范約定先行,盡量避免溝通聯(lián)調(diào)產(chǎn)生的不必要的問題,讓大家身心愉快地專注于各自擅長的領(lǐng)域。
目前現(xiàn)有前后端開發(fā)模式:“后端為主的MVC時代”,如下圖所示:
代碼可維護性得到明顯好轉(zhuǎn),MVC 是個非常好的協(xié)作模式,從架構(gòu)層面讓開發(fā)者懂得什么代碼應該寫在什么地方。為了讓 View 層更簡單干脆,還可以選擇 Velocity、Freemaker 等模板,使得模板里寫不了 Java 代碼??雌饋硎枪δ茏?nèi)趿耍沁@種限制使得前后端分工更清晰。然而依舊并不是那么清晰,這個階段的典型問題是:
總上所述,就跟為什麼要代碼重構(gòu)一樣:
- 關(guān)注點分離
- 職責分離
- 對的人做對的事
- 更好的共建模式
- 快速的反應變化
我們現(xiàn)在要做的前后分離第一階段:“基于 Ajax 帶來的 SPA 時代”,如圖:
這種模式下,前后端的分工非常清晰,前后端的關(guān)鍵協(xié)作點是 Ajax 接口。看起來是如此美妙,但回過頭來看看的話,這與 JSP 時代區(qū)別不大。復雜度從服務端的 JSP 里移到了瀏覽器的 JavaScript,瀏覽器端變得很復雜。類似 Spring MVC,這個時代開始出現(xiàn)瀏覽器端的分層架構(gòu):
對于這一SPA階段,前后端分離有幾個重要挑戰(zhàn):
前后端接口的約定。如果后端的接口一塌糊涂,如果后端的業(yè)務模型不夠穩(wěn)定,那么前端開發(fā)會很痛苦。這一塊在業(yè)界有 API Blueprint 等方案來約定和沉淀接口,==在阿里,不少團隊也有類似嘗試,通過接口規(guī)則、接口平臺等方式來做。有了和后端一起沉淀的接口規(guī)則,還可以用來模擬數(shù)據(jù),使得前后端可以在約定接口后實現(xiàn)高效并行開發(fā)。== 相信這一塊會越做越好。
后端 | 前端 |
---|---|
提供數(shù)據(jù) | 接收數(shù)據(jù),返回數(shù)據(jù) |
處理業(yè)務邏輯 | 處理渲染邏輯 |
Server-side MVC架構(gòu) | Client-side MV* 架構(gòu) |
代碼跑在服務器上 | 代碼跑在瀏覽器上 |
Mock 服務器根據(jù)接口文檔自動生成 Mock 數(shù)據(jù),實現(xiàn)了接口文檔即API:
現(xiàn)在已基本完成了,接口方面的實施:
- 接口返回數(shù)據(jù)即顯示:前端僅做渲染邏輯處理;
- 渲染邏輯禁止跨多個接口調(diào)用;
- 前端關(guān)注交互、渲染邏輯,盡量避免業(yè)務邏輯處理的出現(xiàn);
- 請求響應傳輸數(shù)據(jù)格式:JSON,JSON數(shù)據(jù)盡量簡單輕量,避免多級JSON的出現(xiàn);
GET請求、POST請求==必須包含key為body的入?yún)?,所有請求?shù)據(jù)包裝為JSON格式,并存放到入?yún)ody中==,示例如下:
1. GET請求:
xxx/login?body={"username":"admin","password":"123456","captcha":"scfd","rememberMe":1}
2. POST請求:
{
code: 200,
data: {
message: "success"
}
}
200: 請求處理成功
500: 請求處理失敗
401: 請求未認證,跳轉(zhuǎn)登錄頁
406: 請求未授權(quán),跳轉(zhuǎn)未授權(quán)提示頁
code=200 且 data.message="success": 請求處理成功
code=200 且 data.message!="success": 請求處理成功, 普通消息提示:message內(nèi)容
code=500: 請求處理失敗,警告消息提示:message內(nèi)容
{
code: 200,
data: {
message: "success",
entity: {
id: 1,
name: "XXX",
code: "XXX"
}
}
}
data.entity: 響應返回的實體數(shù)據(jù)
{
code: 200,
data: {
message: "success",
list: [
{
id: 1,
name: "XXX",
code: "XXX"
},
{
id: 2,
name: "XXX",
code: "XXX"
}
]
}
}
data.list: 響應返回的列表數(shù)據(jù)
{
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: 當前頁記錄數(shù)
data.totalCount: 總記錄數(shù)
data.pageNo: 當前頁碼
data.pageSize: 每頁大小
data.totalPage: 總頁數(shù)
由后端接口統(tǒng)一邏輯判定是否選中,通過isSelect標示是否選中,示例如下:
{
code: 200,
data: {
message: "success",
list: [{
id: 1,
name: "XXX",
code: "XXX",
isSelect: 1
}, {
id: 1,
name: "XXX",
code: "XXX",
isSelect: 0
}]
}
}
禁止下拉框、復選框、單選框判定選中邏輯由前端來處理,統(tǒng)一由后端邏輯判定選中返回給前端展示;
關(guān)于Boolean類型,JSON數(shù)據(jù)傳輸中一律使用1/0來標示,1為是/True,0為否/False;
關(guān)于日期類型,JSON數(shù)據(jù)傳輸中一律使用字符串,具體日期格式因業(yè)務而定;
創(chuàng)新互聯(lián)www.cdcxhl.cn,專業(yè)提供香港、美國云服務器,動態(tài)BGP最優(yōu)骨干路由自動選擇,持續(xù)穩(wěn)定高效的網(wǎng)絡助力業(yè)務部署。公司持有工信部辦法的idc、isp許可證, 機房獨有T級流量清洗系統(tǒng)配攻擊溯源,準確進行流量調(diào)度,確保服務器高可用性。佳節(jié)活動現(xiàn)已開啟,新人活動云服務器買多久送多久。
新聞名稱:面試官:你們前后端分離的接口規(guī)范是什么?-創(chuàng)新互聯(lián)
文章出自:http://bm7419.com/article8/diccip.html
成都網(wǎng)站建設公司_創(chuàng)新互聯(lián),為您提供網(wǎng)站維護、微信公眾號、網(wǎng)站導航、建站公司、用戶體驗、虛擬主機
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時需注明來源: 創(chuàng)新互聯(lián)
猜你還喜歡下面的內(nèi)容