一切的開端假設(shè)有這樣一個故事，故事的最開始是要對用戶的信息進(jìn)行管理。用戶的信息主要有：id用戶標(biāo)志符name姓名nickName昵稱password密碼mobilePhone手機號validateCode短信驗證碼gender性別birthday生日state狀態(tài)/正?；蚪胏reateTime注冊日期于是后端開發(fā)者開發(fā)了一系列針對用戶信息進(jìn)行增刪改查的接口：增：/api/user/post刪：/api/user/delete改：/api/user/put查：/api/user/get很好，前端開發(fā)者調(diào)用這四個接口不停增刪改查開心得不行。然后突然有一天，發(fā)現(xiàn)了問題。遇到的問題用戶管理功能中，需要實現(xiàn)用戶賬號密碼的注冊和用戶手機號驗證短信的注冊，而這些前端開發(fā)者調(diào)用的都是/api/user/post接口，只不過通過傳入的參數(shù)值不同來實現(xiàn)：用戶賬號密碼注冊：{nickName:"young",password:"12345"}用戶手機號驗證碼注冊：{mobilePhone:"12345678910",validateCode:"123456"}(這里因為舉例所以只例舉了一個接口被兩個業(yè)務(wù)功能使用的場景。實際項目中已經(jīng)遇到了更多的業(yè)務(wù)功能使用同一個接口)這時候前端開發(fā)者就懵逼了，我調(diào)用的是同一個接口，但是我要實現(xiàn)什么功能卻是根據(jù)我傳入的參數(shù)來確定的，這也太蛋疼了！而且這個例子還是最為簡單的，有些業(yè)務(wù)復(fù)雜的接口根本是看都看不懂！盡管有接口文檔，但是通常來說，前端開發(fā)者依舊會云里霧里。甚至，前端會有這種感想：我是誰，我來自哪里，我為什么要調(diào)用這屎一樣的接口？于是細(xì)分的接口需求就被提了出來。細(xì)分的接口需求簡而言之，就是不再對外直接開放post接口，而是通過提供細(xì)分后的接口來間接調(diào)用。舉個栗子：原先的方案：//不論手機號注冊還是用戶名注冊都來調(diào)用這個接口//前端開發(fā)者表示很懵逼RequestMapping("/post")publicboolpost(Useruser){//sth}改進(jìn)的方案：//隱藏post方法，改為由細(xì)分化的對外接口來調(diào)用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);}通過提供細(xì)分化的接口，使得接口對前端更為友好且沒有二義性。我的問題這種細(xì)分化的接口方案是否是最好的解決方案？通常互聯(lián)網(wǎng)公司進(jìn)行接口細(xì)分化的時候是否也是采用這種方案，還是說有更好的方法？之前有聽說過“后端的后端”的解決方案，有誰知道具體是怎么實現(xiàn)的？另外一個問題是，如果細(xì)分接口的名字很長，比如上文中的/signinbyname，這種時候用全小寫的方式好(/signinbyname)，還是用駝峰式的方式(/signInByName)好？大家一起探討下~