Problems using http status code-PHP Tutorial-php.cn

Problems using http status code

WBOY

Release： 2016-09-19 09:16:30

Original

1241 people have browsed it

As a front-end, I recently started writing the back-end, and I encountered some restful design problems. I hope you can answer them.
restful specification particularly emphasizes the use of HTTP Status Codes, but I have some doubts when using it. Especially when it comes to returning error messages.
When I use it myself, I agree on a set of business-related error codes, such as 20001, which represents 'missing xxx field', put it in the http response body and return it, and then write 200 OK in the response header.
For example, when logging in, if there is no password field in the json passed by the front end,
then I will return a 400 Bad Request http message, and the body part of the message is as follows (just an example, keep everything simple):

<code>{
"code":20001,
"message":"缺少password字段"
}</code>

Copy after login

For the above processing method, the main question is:
Sometimes there are business errors and I don’t know which HTTP Status Codes to use. For example, when creating a new user, if the username already exists, then I will not know the body part at this time. It’s easy to do, but which HTTP Status Codes should be used? 400 Bad Request must be wrong, there is no problem with the information sent from the front end, 401 Unauthorized 403 Forbidden and the like cannot be used here, so What should I use for the HTTP Status Codes at this time?
Indeed, many students return 200 OK no matter what the situation is, and then use json to return the error message in the http body part, but I still I feel that HTTP Status Codes is a very important part of restful, and the restful specification also emphasizes its use, so I still hope that everyone can give me some guidance on how to do this part.

Reply content:

As a front-end, I recently started writing back-end, and I encountered some restful design problems. I hope you can answer them.
restful specification particularly emphasizes the use of HTTP Status Codes, but I have some doubts when using it. Especially when it comes to returning error messages.
When I use it myself, I agree on a set of business-related error codes, such as 20001, which represents 'missing xxx field', put it in the http response body and return it, and then write 200 OK in the response header.
For example, when logging in, if there is no password field in the json passed by the front end,
then I will return a 400 Bad Request http message, and the body part of the message is as follows (just an example, keep everything simple):

<code>{
"code":20001,
"message":"缺少password字段"
}</code>

Copy after login

It is recommended to take a look at the http status code list. There are still many 4xx response codes. Generally, 4xx also represents a request error.

The specifications are just general suggestions. You can follow the specifications. You can also make 233 ok. The key is to coordinate well and leave relevant documents...

Suppose it is used in a website-type program. To put it bluntly, the website is for users to see. It is true that the webpage does not exist and will return 404, but the web server will usually do this for us, but simply use a server to respond when something goes wrong. The default page is not enough. The website is for people to see. Users don’t care how scientifically you set the return codes. They won’t buy your account even if you play around with the return codes. Therefore, for websites, commonly used return codes can be given, but the focus is on the displayed page. As for whether the return code is 400, 401 or the like, no matter how particular you are, it is not as concise and clear as an error message prompt page.

For API-type applications, assuming that the API is for front-end ajax, if you give an HTTP protocol status code when the business logic goes wrong, it will only print an error log on the console. If you are using ajax processed by jquery, then it will trigger the error function callback, which is definitely not what you want. The normal approach is to return json data. This json contains the return code and error information. When the error information field in json is displayed. If you use the return code when an error occurs, you will not be able to get the specific error cause in the error callback. You can only display a vague message that an error occurred in operation xxx. This is definitely not what the user wants. This also increases customer service Difficulty, users can only describe a vague problem when describing it to customer service. Of course, there is a hidden problem. Assuming you use a reverse proxy, the front-end program cannot distinguish whether the current illegal return code is returned by the web application or the reverse proxy server.

Suppose you use custom HTTP return codes between APIs between pure servers. You will find that it is not enough for developers to just parse an HTTP return code. They want to know the details of the error. In this case, you have to return a json data. Of course, the reverse proxy problem mentioned above still exists here.

So to sum up, I do not recommend using custom HTTP return codes. Although it is very scientific, it is too academic and impractical. Especially for website applications, 404 or 500 will be returned when a link cannot be found or an uncaught exception occurs, and a friendly error page should be used to carry it when returning. Other logical errors should also be carried by error pages as much as possible.

422 Unprocesable entity - [POST/PUT/PATCH] When creating an object, a validation error occurred.

This feels right

422 Unprocesable entity - [POST/PUT/PATCH] When creating an object, a validation error occurred.

This tip is also good

If there is conflicting information, you can also use 409 Conflict

You can check out the HTTP status code analysis here
http://jingyan.baidu.com/arti...