Httpstatuscode usage problems

As a front-end, I recently started writing back the background and encountered some restful design problems. I hope you can answer them. The restful specification emphasizes the use of HTTPStatusCodes, but I have some doubts when using it. Especially when the error message is returned. I used it myself. as a front-end, I recently started to write back-end and encountered some restful design problems. I hope you can answer them.
The restful specification emphasizes HTTP Status CodesBut I have some questions when using it. Especially in Error message returnedThis one.
When I use it myself, I agree on a set of error codes for the business, such as 20001, which indicates that the 'XXX field is missing 'and put it in the http response body to return, then write 200 OK in the response header.
For example, when login is used, if the json file sent from the front end does not contain the password field,
Then I return 400 Bad RequestAt the same time, the body of the packet is as follows (for example, everything is simplified ):

{"Code": 20001, "message": "password field missing "}

For the above processing method, the main points are:
Sometimes the service error does not know which HTTP Status Codes to use. for example, if the user name already exists, the body part is very interesting at this time, but what should HTTP Status Codes use?400 Bad RequestIt must be wrong. there is no problem with the information sent from the front end,401 Unauthorized 403 ForbiddenAnd so on, so what should the HTTP Status Codes Status code be used at this time?
It is true that many people will return results in whatever situation they use.200 OKAnd thenhttp bodySome errors are returned in json format, but I still thinkHTTP Status CodesIt is a very important part of restful, and the restful specification also emphasizes the use of it. so I still hope you can give me a clear understanding of how to get this part.

Reply content:

As a front-end, I recently started writing back the background and encountered some restful design problems. I hope you can answer them.
The restful specification emphasizesHTTP Status CodesBut I have some questions when using it. Especially inError message returnedThis one.
When I use it myself, I agree on a set of error codes for the business, such as 20001, which indicates that the 'XXX field is missing 'and put it in the http response body to return, then write 200 OK in the response header.
For example, when login is used, if the json file sent from the front end does not contain the password field,
Then I return400 Bad RequestAt the same time, the body of the packet is as follows (for example, everything is simplified ):

{"Code": 20001, "message": "password field missing "}

For the above processing method, the main points are:
Sometimes the service error does not know which HTTP Status Codes to use. for example, if the user name already exists, the body part is very interesting at this time, but what should HTTP Status Codes use?400 Bad RequestIt must be wrong. there is no problem with the information sent from the front end,401 Unauthorized 403 ForbiddenAnd so on, so what should the HTTP Status Codes Status code be used at this time?
It is true that many people will return results in whatever situation they use.200 OKAnd thenhttp bodySome errors are returned in json format, but I still thinkHTTP Status CodesIt is a very important part of restful, and the restful specification also emphasizes the use of it. so I still hope you can give me a clear understanding of how to get this part.

We recommend that you check the http status code list. there are still many 4xx response codes. generally, 4xx also indicates a request error.

The specification is just a general suggestion. you can do it according to the specification.233 okOK, the key is to coordinate well and leave relevant documents...

If it is used in a website-type program, the website will be displayed to the user. it is true that 404 will be returned if the webpage does not exist, but the web server will usually help us with this function, however, when an error occurs, it is not enough to use the default page provided by a server. The website is for people to see. no matter how scientific your return code is, you just play out the return code, and they don't buy your account either. Therefore, for websites, common return codes can be provided, but the focus is on the displayed pages. As for whether the return code is 400 or 401, it is not as concise and clear as an error message prompt page.

For API-based applications, assume that this API is used for front-end ajax. if you provide an HTTP status code when the business logic fails, then it only prints an error log on the console. If you use jquery to process ajax, it will trigger the error function callback. this is definitely not what you want. the normal method is to return json data, this json contains the return code and error message. When an error occurs, the error information field in json is displayed. If you use a return code when an error occurs, you cannot find the specific cause of the error in the error callback. you can only display a fuzzy message and the xxx operation has an error, this is definitely not what the user wants. this increases the difficulty of customer service. when the user describes the problem again with the customer service, he can only describe one fuzzy question. Of course, there is another hidden problem. if you use reverse proxy, the front-end program cannot tell whether the current illegal return code is returned by the web application or the reverse proxy server.

If you use custom HTTP return codes between pure server APIs, you will find that developers are not enough to parse only one HTTP return code. they want to know the error details, at this time, you have to return a json data. Of course, the reverse proxy problem mentioned above still exists here.

To sum up, I do not recommend using custom HTTP return codes. although it is scientific, it is too informative and not practical. In particular, if a link cannot be found for a website application or an exception is not captured, 404 or 500 will be returned, and a friendly error page will be used to carry the response, for other logical errors, try to use error pages.

422 Unprocesable entity-[POST/PUT/PATCH] a verification error occurs when an object is created.

It seems appropriate.

422 Unprocesable entity-[POST/PUT/PATCH] a verification error occurs when an object is created.

This prompt is also good

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

You can check the HTTP status code parsing.
Http://jingyan.baidu.com/arti...