Discussion on the design problem of whim: what is the solution to the interface differentiation of the webApi project?

< H2 > the beginning of everything < / H2 >

suppose there is a story in which the beginning of the story is to manage the user"s information.
the main information of users is:

id 
name 
nickName 
password 
mobilePhone 
validateCode
gender 
birthday 
state /
createTime 

so the back-end developer developed a series of interfaces to add, delete, modify and query user information:

:/api/user/post
:/api/user/delete
:/api/user/put
:/api/user/get

good. The front-end developers are very happy to keep adding, deleting, modifying and checking these four APIs. And then one day, I found a problem.

< H2 > problems encountered < / H2 >

in the user management function, you need to register the user"s account password and the user"s mobile phone number verification SMS. These front-end developers all call the / api/user/post interface, but they are implemented by passing different parameter values:

:
{
    nickName:"young",
    password:"12345"
}
:
{
    mobilePhone:"12345678910",
    validateCode:"123456"
}

(because of the example, only one interface is used by two business functions. In the actual project, we have encountered more business functions using the same interface.) at this time, the front-end developers were confused. I called the same interface, but what function I wanted to implement was determined according to the parameters I passed in. This is so painful! And this example is still the simplest, some business complex interfaces simply can not understand! Although there is interface documentation, generally speaking, front-end developers are still in the clouds. Even, the front end will have this feeling: who am I, where am I from, and why should I call this shit-like interface?
then the subdivided interface requirements are proposed.

< H2 > Interface requirements for breakdown < / H2 >

in short, the post interface is no longer directly open to the outside world, but is called indirectly by providing a subdivided interface.
take a chestnut:
the original scheme:

//
//
RequestMapping("/post")
public bool post(User user){
    //sth
}

improved scheme:

//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);
}

by providing a differentiated interface, the interface is more friendly to the front end and has no ambiguity.

< H2 > my question < / H2 >

is this differentiated interface solution the best solution? Do Internet companies usually use this solution when subdividing their interfaces, or is there a better way? I have heard of the solution of "back-end back-end" before. Who knows exactly how it is implemented?
another problem is that if the name of the subdivision interface is very long, such as / signinbyname, above, is it better to use all lowercase (/ signinbyname), or hump (/ signInByName)?

Let"s discuss ~


I think writing interfaces according to the model does have disadvantages

I think that if the function of the page is determined, the communication standard between the front and rear ends will be timely

if there is little change.

then take interface subdivision

I guess if not subdivided,
the backend also has to write a bunch of logical judgments to implement different functions according to different interface parameters.
the front end is also very tired if there is no good documentation to record what parameters are passed to achieve what functions.

so subdivide it

I think we can take a joint action to verify the feasibility of the front and rear ends.
set aside some time to implement interface segmentation
, then evaluate the development efficiency, etc., evaluate the advantages and disadvantages of interface segmentation, and then decide whether to change it to interface segmentation

.

there is no best way, only a more suitable method

the name of the interface, look at your functional module division
can be written as / login/byname and so on


you have the same problem and said the same thing. "shit interface"
is the same as you do.
if we name it, we use the hump method. It looks clearer.
especially when there are many variable names

paramTypeValue, paramNameValue, paramIdValue

paramtypevalue, paramnamevalue, paramidvalue

I think the hump method in the above line looks more convenient

Menu