假設(shè)有這樣一個(gè)故事,故事的最開始是要對(duì)用戶的信息進(jìn)行管理。
用戶的信息主要有:
id 用戶標(biāo)志符
name 姓名
nickName 昵稱
password 密碼
mobilePhone 手機(jī)號(hào)
validateCode短信驗(yàn)證碼
gender 性別
birthday 生日
state 狀態(tài)/正?;蚪?createTime 注冊(cè)日期
于是后端開發(fā)者開發(fā)了一系列針對(duì)用戶信息進(jìn)行增刪改查的接口:
增:/api/user/post
刪:/api/user/delete
改:/api/user/put
查:/api/user/get
很好,前端開發(fā)者調(diào)用這四個(gè)接口不停增刪改查開心得不行。然后突然有一天,發(fā)現(xiàn)了問題。
用戶管理功能中,需要實(shí)現(xiàn)用戶賬號(hào)密碼的注冊(cè)和用戶手機(jī)號(hào)驗(yàn)證短信的注冊(cè),而這些前端開發(fā)者調(diào)用的都是/api/user/post接口,只不過通過傳入的參數(shù)值不同來實(shí)現(xiàn):
用戶賬號(hào)密碼注冊(cè):
{
nickName:"young",
password:"12345"
}
用戶手機(jī)號(hào)驗(yàn)證碼注冊(cè):
{
mobilePhone:"12345678910",
validateCode:"123456"
}
(這里因?yàn)榕e例所以只例舉了一個(gè)接口被兩個(gè)業(yè)務(wù)功能使用的場(chǎng)景。實(shí)際項(xiàng)目中已經(jīng)遇到了更多的業(yè)務(wù)功能使用同一個(gè)接口)這時(shí)候前端開發(fā)者就懵逼了,我調(diào)用的是同一個(gè)接口,但是我要實(shí)現(xiàn)什么功能卻是根據(jù)我傳入的參數(shù)來確定的,這也太蛋疼了!而且這個(gè)例子還是最為簡(jiǎn)單的,有些業(yè)務(wù)復(fù)雜的接口根本是看都看不懂!盡管有接口文檔,但是通常來說,前端開發(fā)者依舊會(huì)云里霧里。甚至,前端會(huì)有這種感想:我是誰,我來自哪里,我為什么要調(diào)用這屎一樣的接口?
于是細(xì)分的接口需求就被提了出來。
簡(jiǎn)而言之,就是不再對(duì)外直接開放post接口,而是通過提供細(xì)分后的接口來間接調(diào)用。
舉個(gè)栗子:
原先的方案:
//不論手機(jī)號(hào)注冊(cè)還是用戶名注冊(cè)都來調(diào)用這個(gè)接口
//前端開發(fā)者表示很懵逼
RequestMapping("/post")
public bool post(User user){
//sth
}
改進(jìn)的方案:
//隱藏post方法,改為由細(xì)分化的對(duì)外接口來調(diào)用
private bool post(User user) {
//sth
}
//通過手機(jī)號(hào)注冊(cè)
RequestMapping("signinbymobilephone")
public bool signInByMobilePhone(string mobilePhone, string validateCode) {
User user = new User();
user.mobilePhone = mobilePhone;
user.validateCode = validateCode;
return post(user);
}
//通過昵稱注冊(cè)
RequestMapping("signinbyname")
public bool signInByNickName(string nickName, string password) {
User user = new User();
user.nickName = nickName;
user.password = password;
return post(user);
}
通過提供細(xì)分化的接口,使得接口對(duì)前端更為友好且沒有二義性。
這種細(xì)分化的接口方案是否是最好的解決方案?通?;ヂ?lián)網(wǎng)公司進(jìn)行接口細(xì)分化的時(shí)候是否也是采用這種方案,還是說有更好的方法?之前有聽說過“后端的后端”的解決方案,有誰知道具體是怎么實(shí)現(xiàn)的?
另外一個(gè)問題是,如果細(xì)分接口的名字很長(zhǎng),比如上文中的/signinbyname,這種時(shí)候用全小寫的方式好(/signinbyname),還是用駝峰式的方式(/signInByName)好?
大家一起探討下~
我覺得根據(jù)模型來寫接口確實(shí)有弊端
我認(rèn)為如果頁面功能確定的話,變動(dòng)不大的話,前后端溝通規(guī)范及時(shí)
那就采取接口細(xì)分
我猜如果不細(xì)分的話
后端也得寫一堆根據(jù)接口參數(shù)不同來實(shí)現(xiàn)不同功能的邏輯判斷
前端如果沒有好的文檔來記錄傳什么參數(shù)來實(shí)現(xiàn)什么功能的話,也是很累的
所以就細(xì)分唄
我覺得可以聯(lián)合前后端來個(gè)驗(yàn)證可行性的行動(dòng)
拿出一些時(shí)間,來實(shí)施接口細(xì)分
然后評(píng)判一下開發(fā)效率等等,評(píng)價(jià)一下接口細(xì)分的優(yōu)點(diǎn)缺點(diǎn),再?zèng)Q定是否改成接口細(xì)分
沒有最好的方法,只有更合適的方法
接口名稱的話,看你功能模塊劃分
可以寫成/login/byname之類的
北大青鳥APTECH成立于1999年。依托北京大學(xué)優(yōu)質(zhì)雄厚的教育資源和背景,秉承“教育改變生活”的發(fā)展理念,致力于培養(yǎng)中國(guó)IT技能型緊缺人才,是大數(shù)據(jù)專業(yè)的國(guó)家
達(dá)內(nèi)教育集團(tuán)成立于2002年,是一家由留學(xué)海歸創(chuàng)辦的高端職業(yè)教育培訓(xùn)機(jī)構(gòu),是中國(guó)一站式人才培養(yǎng)平臺(tái)、一站式人才輸送平臺(tái)。2014年4月3日在美國(guó)成功上市,融資1
北大課工場(chǎng)是北京大學(xué)校辦產(chǎn)業(yè)為響應(yīng)國(guó)家深化產(chǎn)教融合/校企合作的政策,積極推進(jìn)“中國(guó)制造2025”,實(shí)現(xiàn)中華民族偉大復(fù)興的升級(jí)產(chǎn)業(yè)鏈。利用北京大學(xué)優(yōu)質(zhì)教育資源及背
博為峰,中國(guó)職業(yè)人才培訓(xùn)領(lǐng)域的先行者
曾工作于聯(lián)想擔(dān)任系統(tǒng)開發(fā)工程師,曾在博彥科技股份有限公司擔(dān)任項(xiàng)目經(jīng)理從事移動(dòng)互聯(lián)網(wǎng)管理及研發(fā)工作,曾創(chuàng)辦藍(lán)懿科技有限責(zé)任公司從事總經(jīng)理職務(wù)負(fù)責(zé)iOS教學(xué)及管理工作。
浪潮集團(tuán)項(xiàng)目經(jīng)理。精通Java與.NET 技術(shù), 熟練的跨平臺(tái)面向?qū)ο箝_發(fā)經(jīng)驗(yàn),技術(shù)功底深厚。 授課風(fēng)格 授課風(fēng)格清新自然、條理清晰、主次分明、重點(diǎn)難點(diǎn)突出、引人入勝。
精通HTML5和CSS3;Javascript及主流js庫(kù),具有快速界面開發(fā)的能力,對(duì)瀏覽器兼容性、前端性能優(yōu)化等有深入理解。精通網(wǎng)頁制作和網(wǎng)頁游戲開發(fā)。
具有10 年的Java 企業(yè)應(yīng)用開發(fā)經(jīng)驗(yàn)。曾經(jīng)歷任德國(guó)Software AG 技術(shù)顧問,美國(guó)Dachieve 系統(tǒng)架構(gòu)師,美國(guó)AngelEngineers Inc. 系統(tǒng)架構(gòu)師。