一切的開端假設有這樣一個故事,故事的最開始是要對用戶的信息進行管理。用戶的信息主要有:id用戶標志符name姓名nickName昵稱password密碼mobilePhone手機號validateCode短信驗證碼gender性別birthday生日state狀態/正?;蚪胏reateTime注冊日期于是后端開發者開發了一系列針對用戶信息進行增刪改查的接口:增:/api/user/post刪:/api/user/delete改:/api/user/put查:/api/user/get很好,前端開發者調用這四個接口不停增刪改查開心得不行。然后突然有一天,發現了問題。遇到的問題用戶管理功能中,需要實現用戶賬號密碼的注冊和用戶手機號驗證短信的注冊,而這些前端開發者調用的都是/api/user/post接口,只不過通過傳入的參數值不同來實現:用戶賬號密碼注冊:{nickName:"young",password:"12345"}用戶手機號驗證碼注冊:{mobilePhone:"12345678910",validateCode:"123456"}(這里因為舉例所以只例舉了一個接口被兩個業務功能使用的場景。實際項目中已經遇到了更多的業務功能使用同一個接口)這時候前端開發者就懵逼了,我調用的是同一個接口,但是我要實現什么功能卻是根據我傳入的參數來確定的,這也太蛋疼了!而且這個例子還是最為簡單的,有些業務復雜的接口根本是看都看不懂!盡管有接口文檔,但是通常來說,前端開發者依舊會云里霧里。甚至,前端會有這種感想:我是誰,我來自哪里,我為什么要調用這屎一樣的接口?于是細分的接口需求就被提了出來。細分的接口需求簡而言之,就是不再對外直接開放post接口,而是通過提供細分后的接口來間接調用。舉個栗子:原先的方案://不論手機號注冊還是用戶名注冊都來調用這個接口//前端開發者表示很懵逼RequestMapping("/post")publicboolpost(Useruser){//sth}改進的方案://隱藏post方法,改為由細分化的對外接口來調用privateboolpost(Useruser){//sth}//通過手機號注冊RequestMapping("signinbymobilephone")publicboolsignInByMobilePhone(stringmobilePhone,stringvalidateCode){Useruser=newUser();user.mobilePhone=mobilePhone;user.validateCode=validateCode;returnpost(user);}//通過昵稱注冊RequestMapping("signinbyname")publicboolsignInByNickName(stringnickName,stringpassword){Useruser=newUser();user.nickName=nickName;user.password=password;returnpost(user);}通過提供細分化的接口,使得接口對前端更為友好且沒有二義性。我的問題這種細分化的接口方案是否是最好的解決方案?通?;ヂ摼W公司進行接口細分化的時候是否也是采用這種方案,還是說有更好的方法?之前有聽說過“后端的后端”的解決方案,有誰知道具體是怎么實現的?另外一個問題是,如果細分接口的名字很長,比如上文中的/signinbyname,這種時候用全小寫的方式好(/signinbyname),還是用駝峰式的方式(/signInByName)好?大家一起探討下~
突發奇想的設計問題探討:webApi項目接口細分化的解決方案是怎樣的?
拉風的咖菲貓
2019-05-12 14:17:00