About restful, the description in the tp3.2 manual feels straight and clear, as follows
Function Traditional mode REST mode
List all users GET /users/list GET /users
List user information with ID 1 GET /users/show/id/1 GET /users/1
Insert a new user POST /users/add POST /users
Update user information with ID 1 POST /users/mdy/id/1 PUT /users/1
Delete user with ID 1 POST /users/delete/id/1 DELETE /users/1
The get method is easy to understand. It is to judge the parameters and perform different operations. For example, whether the above requires all users or individual user information, it can be judged by whether there is an ID. This is no problem, but my current question is, other such as As for the update operation, if I have two interfaces, one is to modify the user's personal information, and the other is to modify only the user's mobile phone. Both modify user information. You can use PUT /users/1 to modify personal information, but what about modifying the user's mobile phone? , I want to pass in one more parameter such as PUT /users/1/2 to perform different modification operations based on parameters? Or create a new controller such as PUT /usersPhone/1? If it's the latter, it's too troublesome, right?
Tell the truth. This is not a restful design principle at all. There must be no verbs in the path first...
put can have a body, so it can be placed in the body.
The body of POST can take parameters.
For example, if you bring
With this parameter, the background can know that the mobile phone number needs to be modified.
You can modify personal information through PUT /users/1. 1 corresponds to the user's id, which corresponds to the modification of a record. The user's mobile phone is a field in the user information. PUT /users/1 The user information you need to modify You still need to pass it through json for modification
RESTful mode:
http(s)://server.com/app-name/{version}/{domain}/{rest-convention}
Here, {version} represents the version information of the api. {domain} is an area that you can use to define any technical (for example: security - allow specified users to access this area.) or business reasons. (For example: the same functions are under the same prefix.)
{rest-convention} represents the agreed set of REST interfaces in this domain.
REST interface specification:
http://www.coderli.com/transl...