Usage issues with HTTP status code

As a front-end, recently began to write backstage, encountered some restful design problems, I hope that the great God to answer you.
The restful specification emphasizes in particular HTTP Status CodesUse, but I have some doubts when I use it. Especially in return error messageThis piece.
My own use is a good set of business error code, such as 20001, representing the ' missing xxx field ', put him in the HTTP response body inside return, and then in the response head inside write good, such as.
For example, when login, if the front end of the JSON there is no password field,
Then I return a 400 Bad RequestHTTP message, while the body part of the message is as follows (just for example, ha, basics):

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

The main question for the above approach is:
Sometimes business errors do not know which HTTP status Codes, such as new users, if the user name already exists, then I this time the body part is very good, but the HTTP status Codes should use which 400 Bad Request ? Certainly wrong, people's front-end transmission of information no problem, 401 Unauthorized 403 Forbidden such as the feeling can not be used in this, so this time the HTTP status Codes status code should use what?
It's true that a lot of students go back in whatever situation they're using, 200 OK and then http body return the error message in part with JSON, but I still think it's a HTTP Status Codes very important part of restful, and the restful norm emphasizes its use, So I hope you will show me the way, this part of how to do.

Reply content:

As a front-end, recently began to write backstage, encountered some restful design problems, I hope that the great God to answer you.
The RESTful specification emphasizes the use in particular HTTP Status Codes , but I have some doubts when I use it. Especially in the return error message this block.
My own use is a good set of business error code, such as 20001, representing the ' missing xxx field ', put him in the HTTP response body inside return, and then in the response head inside write good, such as.
For example, when login, if the front end of the JSON there is no password field,
Then I return an 400 Bad Request HTTP message with the body part of the message as follows (just for example, ha, basics):

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

The main question for the above approach is:
Sometimes business errors do not know which HTTP status Codes, such as new users, if the user name already exists, then I this time the body part is very good, but the HTTP status Codes should use which 400 Bad Request ? Certainly wrong, people's front-end transmission of information no problem, 401 Unauthorized 403 Forbidden such as the feeling can not be used in this, so this time the HTTP status Codes status code should use what?
It's true that a lot of students go back in whatever situation they're using, 200 OK and then http body return the error message in part with JSON, but I still think it's a HTTP Status Codes very important part of restful, and the restful norm emphasizes its use, So I hope you will show me the way, this part of how to do.

Recommended to look at the HTTP status Code list, 4xx response code is still a lot of, General 4xx is also representative of the request error.

Specification is only a general recommendation, according to the norms can be, you do a 233 ok line, the key is to coordinate well, leaving the relevant documents ...

Assumptions are used in the site-type program, the site is plainly for users to see, it is true that the Web page does not exist to return 404, but this feature Web server will generally help us do, but simple in error when using a server to give the default page is not enough, the site is for people to see, Users don't care how much science your return code sets, you just play the return code out of the flowers and they don't buy your account. So, for the site, you can give a common return code, but the focus is on the display of the page. As to whether the return code is 400 401 and so on, you do not pay attention to an error message prompt page to concise and crisp.

For API-type applications, suppose this API is for front-end Ajax, and 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 jquery to handle Ajax, then it will trigger the error function callback, which is certainly not what you want, it is normal to return the JSON data, this JSON with a return code and error information, in the case of errors in the JSON error message field display. If you use the return code in error, then in the error callback can not get the specific cause of the error, you only display a vague information, operation XXX Error, this is certainly not what the user wants, which at the same time increased the difficulty of customer service, users and customer service description can only describe a vague problem. Of course there is a hidden problem, assuming that you use a reverse proxy, the front-end program can not distinguish between the current illegal return code is returned by the Web application, or the reverse proxy server returned.

Assuming you use a custom HTTP return code between the pure server APIs, you'll find that developers just parse an HTTP return code is not enough, they want to know the details of the error, and then you have to return a JSON data. Of course the problem with the reverse proxy above is still there.

So in summary, I do not recommend the use of custom HTTP return code, although it is very scientific, but it is too academic, not practical. This is especially true if the Web application encounters a link that cannot be found or catches an exception, returns 404 or 500, and is returned with a friendly error page to be hosted, and other logic errors are also used to host the error page as much as possible.

422 unprocesable Entity-[Post/put/patch] A validation error occurs when an object is created.

It feels right.

422 unprocesable Entity-[Post/put/patch] A validation error occurs when an object is created.

That's a good tip.

If you have conflicting information, you can also use 409 Conflict

This way the HTTP status code parsing can be seen
Http://jingyan.baidu.com/arti ...

