阿里面試官:小伙子,你給我說一下前后端分離的接口規(guī)范是什么捆毫?

1. 前言

隨著互聯(lián)網(wǎng)的高速發(fā)展闪湾,前端頁面的展示、交互體驗(yàn)越來越靈活绩卤、炫麗途样,響應(yīng)體驗(yàn)也要求越來越高江醇,后端服務(wù)的高并發(fā)、高可用何暇、高性能陶夜、高擴(kuò)展等特性的要求也愈加苛刻,從而導(dǎo)致前后端研發(fā)各自專注于自己擅長的領(lǐng)域深耕細(xì)作赖晶。

然而帶來的另一個(gè)問題:前后端的對接界面雙方卻關(guān)注甚少律适,沒有任何接口約定規(guī)范情況下各自擼起袖子就是干,導(dǎo)致我們在產(chǎn)品項(xiàng)目開發(fā)過程中遏插,前后端的接口聯(lián)調(diào)對接
工作量占比在30%-50%左右捂贿,甚至?xí)摺M昂蠖私涌诼?lián)調(diào)對接及系統(tǒng)間的聯(lián)調(diào)對接都是整個(gè)產(chǎn)品項(xiàng)目研發(fā)的軟肋胳嘲。

本文的主要初衷就是規(guī)范約定先行厂僧,盡量避免溝通聯(lián)調(diào)產(chǎn)生的不必要的問題,讓大家身心愉快地專注于各自擅長的領(lǐng)域了牛。

2. 為何要分離

目前現(xiàn)有前后端開發(fā)模式:“后端為主的MVC時(shí)代”颜屠,如下圖所示:

代碼可維護(hù)性得到明顯好轉(zhuǎn),MVC 是個(gè)非常好的協(xié)作模式鹰祸,從架構(gòu)層面讓開發(fā)者懂得什么代碼應(yīng)該寫在什么地方甫窟。為了讓 View 層更簡單干脆,還可以選擇 Velocity蛙婴、Freemaker 等模板粗井,使得模板里寫不了 Java 代碼〗滞迹看起來是功能變?nèi)趿私匠模沁@種限制使得前后端分工更清晰。然而依舊并不是那么清晰餐济,這個(gè)階段的典型問題是:

  1. 前端開發(fā)重度依賴開發(fā)環(huán)境耘擂,開發(fā)效率低。這種架構(gòu)下絮姆,前后端協(xié)作有兩種模式:一種是前端寫demo醉冤,寫好后,讓后端去套模板 篙悯。淘寶早期包括現(xiàn)在依舊有大量業(yè)務(wù)線是這種模式冤灾。好處很明顯,demo 可以本地開發(fā)辕近,很高效。不足是還需要后端套模板匿垄,有可能套錯(cuò)移宅,套完后還需要前端確定归粉,來回溝通調(diào)整的成本比較大。另一種協(xié)作模式是前端負(fù)責(zé)瀏覽器端的所有開發(fā)和服務(wù)器端的 View 層模板開發(fā)漏峰,支付寶是這種模式糠悼。 好處是 UI 相關(guān)的代碼都是前端去寫就好,后端不用太關(guān)注浅乔,不足就是前端開發(fā)重度綁定后端環(huán)境倔喂,環(huán)境成為影響前端開發(fā)效率的重要因素。
  2. 前后端職責(zé)依舊糾纏不清靖苇。 Velocity 模板還是蠻強(qiáng)大的席噩,變量、邏輯贤壁、宏等特性悼枢,依舊可以通過拿到的上下文變量來實(shí)現(xiàn)各種業(yè)務(wù)邏輯。這樣脾拆,只要前端弱勢一點(diǎn)馒索,往往就會(huì)被后端要求在模板層寫出不少業(yè)務(wù)代碼。還有一個(gè)很大的灰色地帶是 Controller名船,頁面路由等功能本應(yīng)該是前端最關(guān)注的绰上,但卻是由后端來實(shí)現(xiàn)。 Controller 本身與 Model 往往也會(huì)糾纏不清渠驼,看了讓人咬牙的業(yè)務(wù)代碼經(jīng)常會(huì)出現(xiàn)在 Controller 層蜈块。這些問題不能全歸結(jié)于程序員的素養(yǎng),否則 JSP 就夠了渴邦。
  3. 對前端發(fā)揮的局限疯趟。 性能優(yōu)化如果只在前端做空間非常有限,于是我們經(jīng)常需要后端合作才能碰撞出火花谋梭,但由于后端框架限制信峻,我們很難使用Comet、Bigpipe等技術(shù)方案來優(yōu)化性能瓮床。

總上所述盹舞,就跟為什麼要代碼重構(gòu)一樣:

  1. 關(guān)注點(diǎn)分離
  2. 職責(zé)分離
  3. 對的人做對的事
  4. 更好的共建模式
  5. 快速的反應(yīng)變化

3. 什么是分離

我們現(xiàn)在要做的前后分離第一階段:“基于 Ajax 帶來的 SPA 時(shí)代”,如圖:

這種模式下隘庄,前后端的分工非常清晰踢步,前后端的關(guān)鍵協(xié)作點(diǎn)是 Ajax 接口。 看起來是如此美妙丑掺,但回過頭來看看的話获印,這與 JSP 時(shí)代區(qū)別不大。復(fù)雜度從服務(wù)端的 JSP 里移到了瀏覽器的 JavaScript街州,瀏覽器端變得很復(fù)雜兼丰。類似 Spring MVC玻孟,這個(gè)時(shí)代開始出現(xiàn)瀏覽器端的分層架構(gòu):

對于這一SPA階段,前后端分離有幾個(gè)重要挑戰(zhàn):

  1. 前后端接口的約定鳍征。 如果后端的接口一塌糊涂黍翎,如果后端的業(yè)務(wù)模型不夠穩(wěn)定,那么前端開發(fā)會(huì)很痛苦艳丛。這一塊在業(yè)界有 API Blueprint 等方案來約定和沉淀接口匣掸,==在阿里,不少團(tuán)隊(duì)也有類似嘗試氮双,通過接口規(guī)則碰酝、接口平臺(tái)等方式來做。有了和后端一起沉淀的接口規(guī)則眶蕉,還可以用來模擬數(shù)據(jù)砰粹,使得前后端可以在約定接口后實(shí)現(xiàn)高效并行開發(fā)。== 相信這一塊會(huì)越做越好造挽。

  2. 前端開發(fā)的復(fù)雜度控制碱璃。 SPA 應(yīng)用大多以功能交互型為主,JavaScript 代碼過十萬行很正常饭入。大量 JS 代碼的組織嵌器,與 View 層的綁定等,都不是容易的事情谐丢。典型的解決方案是業(yè)界的 Backbone爽航,但 Backbone 做的事還很有限,依舊存在大量空白區(qū)域需要挑戰(zhàn)乾忱。

4. 如何做分離

4.1 職責(zé)分離

  1. 前后端僅僅通過異步接口(AJAX/JSONP)來編程
  2. 前后端都各自有自己的開發(fā)流程讥珍,構(gòu)建工具,測試集合
  3. 關(guān)注點(diǎn)分離窄瘟,前后端變得相對獨(dú)立并松耦合
后端 前端
提供數(shù)據(jù) 接收數(shù)據(jù)衷佃,返回?cái)?shù)據(jù)
處理業(yè)務(wù)邏輯 處理渲染邏輯
Server-side MVC架構(gòu) Client-side MV* 架構(gòu)
代碼跑在服務(wù)器上 代碼跑在瀏覽器上

4.2 開發(fā)流程

  1. 后端編寫和維護(hù)接口文檔,在 API 變化時(shí)更新接口文檔
  2. 后端根據(jù)接口文檔進(jìn)行接口開發(fā)
  3. 前端根據(jù)接口文檔進(jìn)行開發(fā) + Mock平臺(tái)
  4. 開發(fā)完成后聯(lián)調(diào)和提交測試

Mock 服務(wù)器根據(jù)接口文檔自動(dòng)生成 Mock 數(shù)據(jù)蹄葱,實(shí)現(xiàn)了接口文檔即API:

4.3 具體實(shí)施

現(xiàn)在已基本完成了氏义,接口方面的實(shí)施:

  1. 接口文檔服務(wù)器:可實(shí)現(xiàn)接口變更實(shí)時(shí)同步給前端展示;
  2. Mock接口數(shù)據(jù)平臺(tái):可實(shí)現(xiàn)接口變更實(shí)時(shí)Mock數(shù)據(jù)給前端使用图云;
  3. 接口規(guī)范定義:很重要惯悠,接口定義的好壞直接影響到前端的工作量和實(shí)現(xiàn)邏輯;具體定義規(guī)范見下節(jié)竣况;

5. 接口規(guī)范V1.0.0

5.1 規(guī)范原則

  1. 接口返回?cái)?shù)據(jù)即顯示:前端僅做渲染邏輯處理克婶;
  2. 渲染邏輯禁止跨多個(gè)接口調(diào)用;
  3. 前端關(guān)注交互、渲染邏輯鸠补,盡量避免業(yè)務(wù)邏輯處理的出現(xiàn)萝风;
  4. 請求響應(yīng)傳輸數(shù)據(jù)格式:JSON,JSON數(shù)據(jù)盡量簡單輕量紫岩,避免多級JSON的出現(xiàn);

5.2 基本格式

5.2.1 請求基本格式

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請求:

5.2.2 響應(yīng)基本格式

{
    code: 200,
    data: {
        message: "success"
    }
}

  1. code : 請求處理狀態(tài)

200: 請求處理成功

500: 請求處理失敗

401: 請求未認(rèn)證勋陪,跳轉(zhuǎn)登錄頁

406: 請求未授權(quán),跳轉(zhuǎn)未授權(quán)提示頁

  1. data.message: 請求處理消息

code=200 且 data.message="success": 請求處理成功

code=200 且 data.message!="success": 請求處理成功, 普通消息提示:message內(nèi)容

code=500: 請求處理失敗硫兰,警告消息提示:message內(nèi)容

5.3 響應(yīng)實(shí)體格式

{
    code: 200,
    data: {
        message: "success",
        entity: {
            id: 1,
            name: "XXX",
            code: "XXX"
        }
    }
}

data.entity: 響應(yīng)返回的實(shí)體數(shù)據(jù)

5.4 響應(yīng)列表格式

{
    code: 200,
    data: {
        message: "success",
        list: [
            {
                id: 1,
                name: "XXX",
                code: "XXX"
            },
            {
                id: 2,
                name: "XXX",
                code: "XXX"
            }
        ]
    }
}

data.list: 響應(yīng)返回的列表數(shù)據(jù)

5.5 響應(yīng)分頁格式

{
    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: 當(dāng)前頁記錄數(shù)
data.totalCount: 總記錄數(shù)
data.pageNo: 當(dāng)前頁碼
data.pageSize: 每頁大小
data.totalPage: 總頁數(shù)

5.6 特殊內(nèi)容規(guī)范

5.6.1 下拉框诅愚、復(fù)選框、單選框

由后端接口統(tǒng)一邏輯判定是否選中劫映,通過isSelect標(biāo)示是否選中违孝,示例如下:

{
    code: 200,
    data: {
        message: "success",
        list: [{
            id: 1,
            name: "XXX",
            code: "XXX",
            isSelect: 1
        }, {
            id: 1,
            name: "XXX",
            code: "XXX",
            isSelect: 0
        }]
    }
}

禁止下拉框、復(fù)選框泳赋、單選框判定選中邏輯由前端來處理雌桑,統(tǒng)一由后端邏輯判定選中返回給前端展示;

5.6.2 Boolean類型

關(guān)于Boolean類型祖今,JSON數(shù)據(jù)傳輸中一律使用1/0來標(biāo)示校坑,1為是/True,0為否/False千诬;

5.6.3 日期類型

關(guān)于日期類型耍目,JSON數(shù)據(jù)傳輸中一律使用字符串,具體日期格式因業(yè)務(wù)而定徐绑;

最后

歡迎大家關(guān)注我的公眾號:前程有光邪驮,金三銀四跳槽面試季,整理了1000多道將近500多頁pdf文檔的Java面試題資料泵三,文章都會(huì)在里面更新耕捞,整理的資料也會(huì)放在里面。

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末烫幕,一起剝皮案震驚了整個(gè)濱河市俺抽,隨后出現(xiàn)的幾起案子,更是在濱河造成了極大的恐慌较曼,老刑警劉巖磷斧,帶你破解...
    沈念sama閱讀 221,820評論 6 515
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件,死亡現(xiàn)場離奇詭異,居然都是意外死亡弛饭,警方通過查閱死者的電腦和手機(jī)冕末,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 94,648評論 3 399
  • 文/潘曉璐 我一進(jìn)店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來侣颂,“玉大人档桃,你說我怎么就攤上這事°旧梗” “怎么了藻肄?”我有些...
    開封第一講書人閱讀 168,324評論 0 360
  • 文/不壞的土叔 我叫張陵,是天一觀的道長拒担。 經(jīng)常有香客問我嘹屯,道長,這世上最難降的妖魔是什么从撼? 我笑而不...
    開封第一講書人閱讀 59,714評論 1 297
  • 正文 為了忘掉前任州弟,我火速辦了婚禮,結(jié)果婚禮上低零,老公的妹妹穿的比我還像新娘婆翔。我一直安慰自己,他們只是感情好毁兆,可當(dāng)我...
    茶點(diǎn)故事閱讀 68,724評論 6 397
  • 文/花漫 我一把揭開白布浙滤。 她就那樣靜靜地躺著,像睡著了一般气堕。 火紅的嫁衣襯著肌膚如雪纺腊。 梳的紋絲不亂的頭發(fā)上,一...
    開封第一講書人閱讀 52,328評論 1 310
  • 那天茎芭,我揣著相機(jī)與錄音揖膜,去河邊找鬼。 笑死梅桩,一個(gè)胖子當(dāng)著我的面吹牛壹粟,可吹牛的內(nèi)容都是我干的。 我是一名探鬼主播宿百,決...
    沈念sama閱讀 40,897評論 3 421
  • 文/蒼蘭香墨 我猛地睜開眼趁仙,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了垦页?” 一聲冷哼從身側(cè)響起雀费,我...
    開封第一講書人閱讀 39,804評論 0 276
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎痊焊,沒想到半個(gè)月后盏袄,有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體忿峻,經(jīng)...
    沈念sama閱讀 46,345評論 1 318
  • 正文 獨(dú)居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點(diǎn)故事閱讀 38,431評論 3 340
  • 正文 我和宋清朗相戀三年辕羽,在試婚紗的時(shí)候發(fā)現(xiàn)自己被綠了逛尚。 大學(xué)時(shí)的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點(diǎn)故事閱讀 40,561評論 1 352
  • 序言:一個(gè)原本活蹦亂跳的男人離奇死亡刁愿,死狀恐怖绰寞,靈堂內(nèi)的尸體忽然破棺而出,到底是詐尸還是另有隱情酌毡,我是刑警寧澤克握,帶...
    沈念sama閱讀 36,238評論 5 350
  • 正文 年R本政府宣布,位于F島的核電站枷踏,受9級特大地震影響,放射性物質(zhì)發(fā)生泄漏掰曾。R本人自食惡果不足惜旭蠕,卻給世界環(huán)境...
    茶點(diǎn)故事閱讀 41,928評論 3 334
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望旷坦。 院中可真熱鬧掏熬,春花似錦、人聲如沸秒梅。這莊子的主人今日做“春日...
    開封第一講書人閱讀 32,417評論 0 24
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽捆蜀。三九已至疮丛,卻和暖如春,著一層夾襖步出監(jiān)牢的瞬間辆它,已是汗流浹背誊薄。 一陣腳步聲響...
    開封第一講書人閱讀 33,528評論 1 272
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機(jī)就差點(diǎn)兒被人妖公主榨干…… 1. 我叫王不留锰茉,地道東北人呢蔫。 一個(gè)月前我還...
    沈念sama閱讀 48,983評論 3 376
  • 正文 我出身青樓,卻偏偏與公主長得像飒筑,于是被迫代替她去往敵國和親片吊。 傳聞我的和親對象是個(gè)殘疾皇子,可洞房花燭夜當(dāng)晚...
    茶點(diǎn)故事閱讀 45,573評論 2 359