Use of http status code

  node.js, question

As a front end, I started writing backstage recently and encountered some problems in restful design. I hope you can answer them.
The restful specification places special emphasis onHTTP Status CodesHowever, I have some doubts when I use it. Especially inReturns an error messageThis one.
When I used it myself, I agreed on a set of business error codes, such as 20001, which means’ missing xxx field’, put it in http response body to return, and then write 200 OK in the response header.
For example, when login in, if json passed from the front end does not contain the password field,
Then I will return to one400 Bad RequestAt the same time, the body part of the message is as follows (just give an example, everything is simple):

bracket
 "code":20001,
 "message": "Missing password Field"
 bracket

For the above treatment, the main question is:
Sometimes I don’t know which HTTP Status Codes to use for business errors, for example, for new users. if the user name already exists, then I am very good at the body part at this time, but which HTTP Status Codes should I use?400 Bad RequestIt must be wrong, the information from the front end of the family is no problem.401 Unauthorized 403 ForbiddenSuch feelings cannot be used here either, so what should the HTTP Status Codes use at this time?
It is true that many students return no matter what situation they use.200 OK, and then inhttp bodySome use json to return error messages, but I still thinkHTTP Status CodesIt is an important part of restful, and the restful specification also emphasizes the use of it, so I still hope that everyone can show me a clear path and how to do this part.

Assuming that it is used in a website-type program, the website is for users to see in plain English. It is true that there is no website to return 404, but this function is usually done by a web server for us. However, it is not enough to simply use the default page given by a server when an error occurs. The website is for people to see. Users do not care how scientific your return code is, even if you play out the return code, they will not buy your account. Therefore, for websites, common return codes can be given, but the focus is on the displayed pages. As to whether the return code is 400 401 or not, you should pay more attention to it than a simple and lively error message page.

For API-type applications, suppose this API is for front-end ajax. If you give an HTTP protocol status code when business logic goes wrong, it will only print an error log on the console. If you use jquery to process ajax, it will trigger an error function callback, which is definitely not what you want. The normal way is to return json data, which contains a return code and error information. When an error occurs, the error information field in json will be displayed. If you use the return code when making an error, you cannot get the specific error reason in the error callback, you can only display a vague message, and the operation xxx made an error, which is definitely not what the user wants, which increases the difficulty of customer service at the same time, and the user can only describe a vague problem when describing with customer service again. 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.

Assuming that you use custom HTTP return codes between APIs between pure servers, you will find that it is not enough for developers to parse only one HTTP return code. They want to know the details of the error, and at this time you have to return a json data. Of course, the problem of reverse proxy mentioned above still exists here.

Therefore, in summary, I do not recommend using custom HTTP return codes. Although it is scientific, it is too pedantic and impractical. Especially for website applications that cannot find links or do not catch exceptions, they only return 404 or 500. When returning, they should use friendly error pages to load, and other logical errors should also use error pages to load as much as possible.