鍍金池/ 問答/Java  UI  HTML/ 突發(fā)奇想的設(shè)計問題探討:webApi項(xiàng)目接口細(xì)分化的解決方案是怎樣的?

突發(fā)奇想的設(shè)計問題探討:webApi項(xiàng)目接口細(xì)分化的解決方案是怎樣的?

一切的開端

假設(shè)有這樣一個故事,故事的最開始是要對用戶的信息進(jìn)行管理。
用戶的信息主要有:

id 用戶標(biāo)志符
name 姓名
nickName 昵稱
password 密碼
mobilePhone 手機(jī)號
validateCode短信驗(yàn)證碼
gender 性別
birthday 生日
state 狀態(tài)/正?;蚪?createTime 注冊日期

于是后端開發(fā)者開發(fā)了一系列針對用戶信息進(jìn)行增刪改查的接口:

增:/api/user/post
刪:/api/user/delete
改:/api/user/put
查:/api/user/get

很好,前端開發(fā)者調(diào)用這四個接口不停增刪改查開心得不行。然后突然有一天,發(fā)現(xiàn)了問題。

遇到的問題

用戶管理功能中,需要實(shí)現(xiàn)用戶賬號密碼的注冊和用戶手機(jī)號驗(yàn)證短信的注冊,而這些前端開發(fā)者調(diào)用的都是/api/user/post接口,只不過通過傳入的參數(shù)值不同來實(shí)現(xiàn):

用戶賬號密碼注冊:
{
    nickName:"young",
    password:"12345"
}
用戶手機(jī)號驗(yàn)證碼注冊:
{
    mobilePhone:"12345678910",
    validateCode:"123456"
}

(這里因?yàn)榕e例所以只例舉了一個接口被兩個業(yè)務(wù)功能使用的場景。實(shí)際項(xiàng)目中已經(jīng)遇到了更多的業(yè)務(wù)功能使用同一個接口)這時候前端開發(fā)者就懵逼了,我調(diào)用的是同一個接口,但是我要實(shí)現(xiàn)什么功能卻是根據(jù)我傳入的參數(shù)來確定的,這也太蛋疼了!而且這個例子還是最為簡單的,有些業(yè)務(wù)復(fù)雜的接口根本是看都看不懂!盡管有接口文檔,但是通常來說,前端開發(fā)者依舊會云里霧里。甚至,前端會有這種感想:我是誰,我來自哪里,我為什么要調(diào)用這屎一樣的接口?
于是細(xì)分的接口需求就被提了出來。

細(xì)分的接口需求

簡而言之,就是不再對外直接開放post接口,而是通過提供細(xì)分后的接口來間接調(diào)用。
舉個栗子:
原先的方案:

//不論手機(jī)號注冊還是用戶名注冊都來調(diào)用這個接口
//前端開發(fā)者表示很懵逼
RequestMapping("/post")
public bool post(User user){
    //sth
}

改進(jìn)的方案:

//隱藏post方法,改為由細(xì)分化的對外接口來調(diào)用
private bool post(User user) {
    //sth
}

//通過手機(jī)號注冊
RequestMapping("signinbymobilephone")
public bool signInByMobilePhone(string mobilePhone, string validateCode) {
    User user = new User();
    user.mobilePhone = mobilePhone;
    user.validateCode = validateCode;
    return post(user);
}

//通過昵稱注冊
RequestMapping("signinbyname")
public bool signInByNickName(string nickName, string password) {
    User user = new User();
    user.nickName = nickName;
    user.password = password;
    return post(user);
}

通過提供細(xì)分化的接口,使得接口對前端更為友好且沒有二義性。

我的問題

這種細(xì)分化的接口方案是否是最好的解決方案?通?;ヂ?lián)網(wǎng)公司進(jìn)行接口細(xì)分化的時候是否也是采用這種方案,還是說有更好的方法?之前有聽說過“后端的后端”的解決方案,有誰知道具體是怎么實(shí)現(xiàn)的?
另外一個問題是,如果細(xì)分接口的名字很長,比如上文中的/signinbyname,這種時候用全小寫的方式好(/signinbyname),還是用駝峰式的方式(/signInByName)好?

大家一起探討下~

回答
編輯回答
傲嬌范

我覺得根據(jù)模型來寫接口確實(shí)有弊端

我認(rèn)為如果頁面功能確定的話,變動不大的話,前后端溝通規(guī)范及時

那就采取接口細(xì)分

我猜如果不細(xì)分的話
后端也得寫一堆根據(jù)接口參數(shù)不同來實(shí)現(xiàn)不同功能的邏輯判斷
前端如果沒有好的文檔來記錄傳什么參數(shù)來實(shí)現(xiàn)什么功能的話,也是很累的

所以就細(xì)分唄

我覺得可以聯(lián)合前后端來個驗(yàn)證可行性的行動
拿出一些時間,來實(shí)施接口細(xì)分
然后評判一下開發(fā)效率等等,評價一下接口細(xì)分的優(yōu)點(diǎn)缺點(diǎn),再決定是否改成接口細(xì)分

沒有最好的方法,只有更合適的方法

接口名稱的話,看你功能模塊劃分
可以寫成/login/byname之類的

2018年8月11日 02:04
編輯回答
祉小皓

跟你遇到一樣的問題,說過一樣的話?!笆阂粯拥慕涌凇?br>跟你的做法一樣。
命名的話,我們用的駝峰法??粗容^清晰。
尤其變量名比較多的時候

paramTypeValue、paramNameValue、paramIdValue

paramtypevalue、paramnamevalue、paramidvalue

我覺得上面一行的駝峰法看著更方便

2018年6月14日 16:03