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

Question

一切的开端
假设有这样一个故事，故事的最开始是要对用户的信息进行管理。用户的信息主要有：
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")
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);
}
通过提供细分化的接口，使得接口对前端更为友好且没有二义性。
我的问题
这种细分化的接口方案是否是最好的解决方案？通常互联网公司进行接口细分化的时候是否也是采用这种方案，还是说有更好的方法？之前有听说过“后端的后端”的解决方案，有谁知道具体是怎么实现的？另外一个问题是，如果细分接口的名字很长，比如上文中的/signinbyname，这种时候用全小写的方式好(/signinbyname)，还是用驼峰式的方式(/signInByName)好？
大家一起探讨下~

Answer 1

我觉得根据模型来写接口确实有弊端我认为如果页面功能确定的话，变动不大的话，前后端沟通规范及时那就采取接口细分我猜如果不细分的话后端也得写一堆根据接口参数不同来实现不同功能的逻辑判断前端如果没有好的文档来记录传什么参数来实现什么功能的话，也是很累的所以就细分呗我觉得可以联合前后端来个验证可行性的行动拿出一些时间，来实施接口细分然后评判一下开发效率等等，评价一下接口细分的优点缺点,再决定是否改成接口细分没有最好的方法，只有更合适的方法接口名称的话，看你功能模块划分可以写成/login/byname之类的

Answer 2

跟你遇到一样的问题，说过一样的话。“屎一样的接口”跟你的做法一样。命名的话，我们用的驼峰法。看着比较清晰。尤其变量名比较多的时候paramTypeValue、paramNameValue、paramIdValueparamtypevalue、paramnamevalue、paramidvalue我觉得上面一行的驼峰法看着更方便