突发奇想的设计问题探讨：webApi项目接口细分化的解决方案是怎样的？

发布于 2022-09-07 21:24:51 字数 1967 浏览 27 评论 0

一切的开端

假设有这样一个故事，故事的最开始是要对用户的信息进行管理。
用户的信息主要有：

id 用户标志符
name 姓名
nickName 昵称
password 密码
mobilePhone 手机号
validateCode短信验证码
gender 性别
birthday 生日
state 状态/正常或禁用
createTime 注册日期

于是后端开发者开发了一系列针对用户信息进行增删改查的接口：

增：/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")
public bool post(User user){
    //sth
}

改进的方案：

//隐藏post方法，改为由细分化的对外接口来调用
private bool post(User user) {
    //sth
}

//通过手机号注册
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);
}

通过提供细分化的接口，使得接口对前端更为友好且没有二义性。

我的问题

这种细分化的接口方案是否是最好的解决方案？通常互联网公司进行接口细分化的时候是否也是采用这种方案，还是说有更好的方法？之前有听说过“后端的后端”的解决方案，有谁知道具体是怎么实现的？
另外一个问题是，如果细分接口的名字很长，比如上文中的/signinbyname，这种时候用全小写的方式好(/signinbyname)，还是用驼峰式的方式(/signInByName)好？

大家一起探讨下~

分享到QQ

分享到微博