http status code的使用问题

作为一个前端,最近开始写后台,遇到了一些restful设计上的问题,希望各位大神解答一下。
restful规范特别的强调了HTTP Status Codes的使用，但是我在使用的时候却有一些疑惑。尤其是在返回错误信息这块。
我自己使用时是约定好一套关于业务的错误码，比如20001,代表'缺少xxx字段',把他放在http response body里面返回，然后在response头里面写好200 OK之类的。
比如login的时候,假如前端传过来的json里面没有password字段,
那我返回一个400 Bad Request的http报文,同时报文的body部分如下(仅仅举个例子哈,一切从简):

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

对于上面这样的处理方式,主要的疑问点在于:
有的时候的业务上的错误不知道该用哪个HTTP Status Codes,比如说新建用户,如果说用户名已存在,那我这个时候body部分很好搞,但是HTTP Status Codes应该用哪个呢?400 Bad Request肯定不对吧,人家前端传过来的信息没有问题,401 Unauthorized 403 Forbidden之类的感觉也不能用在这,所以这个时候的HTTP Status Codes状态码到底应该用什么呢?
确实有很多同学在使用时是不管什么情况都返回200 OK,然后在http body部分用json去返回错误信息,但我还是觉得HTTP Status Codes是restful中很重要的一部分,restful规范也很强调对其的使用,所以我还是希望大家给我指条明路,这部分到底该怎么弄。

回复内容：

作为一个前端,最近开始写后台,遇到了一些restful设计上的问题,希望各位大神解答一下。
restful规范特别的强调了HTTP Status Codes的使用，但是我在使用的时候却有一些疑惑。尤其是在返回错误信息这块。
我自己使用时是约定好一套关于业务的错误码，比如20001,代表'缺少xxx字段',把他放在http response body里面返回，然后在response头里面写好200 OK之类的。
比如login的时候,假如前端传过来的json里面没有password字段,
那我返回一个400 Bad Request的http报文,同时报文的body部分如下(仅仅举个例子哈,一切从简):

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

对于上面这样的处理方式,主要的疑问点在于:
有的时候的业务上的错误不知道该用哪个HTTP Status Codes,比如说新建用户,如果说用户名已存在,那我这个时候body部分很好搞,但是HTTP Status Codes应该用哪个呢?400 Bad Request肯定不对吧,人家前端传过来的信息没有问题,401 Unauthorized 403 Forbidden之类的感觉也不能用在这,所以这个时候的HTTP Status Codes状态码到底应该用什么呢?
确实有很多同学在使用时是不管什么情况都返回200 OK,然后在http body部分用json去返回错误信息,但我还是觉得HTTP Status Codes是restful中很重要的一部分,restful规范也很强调对其的使用,所以我还是希望大家给我指条明路,这部分到底该怎么弄。

建议看一下http status code列表，4xx的响应码还是很多的，一般4xx也是代表是请求错误。

规范只是大体建议，按照规范来可以，你搞个233 ok也行，关键是协调好，留下相关文档...

假设是在网站型的程序中使用，网站说白了是给用户看的，诚然网页不存在要返回404，但是这个功能web服务器一般会帮我们做，不过单纯的在出错的时候使用一个服务器给出的默认页面是不够的，网站是给人看的，用户才不管你返回码设置的有多科学，你就是把返回码玩出花来，他们也不买你的帐。所以说，对于网站来说，可以给出常用的返回码，但是重点在于展示的页面。至于是不是返回码是400 401之类的，你做再讲究不如一个出错信息提示页来的简洁明快。

对于API型的应用来说，假设这个API是给前端ajax用的，如果你在业务逻辑出错的时候给出了一个HTTP协议的状态码，那么它只会在控制台上打印一条错误日志。如果你用的是jquery来处理的ajax，那么它就会触发error函数回调，这肯定不是你想要的，正常的做法是返回json数据，这个json中带有返回码和错误信息，在出错的时候将json中的错误信息字段显示出来。如果你在出错时用返回码，则在error回调中还拿不到具体的错误原因，你只能显示一个模糊的信息，操作xxx出错了，这肯定不是用户想要的，这同时增加了客服的难度，用户再跟客服描述的时候只能描述一个模糊的问题。当然还有一个隐藏的问题，假设你使用了反向代理，前端程序也没法区分当前的非法的返回码到底是web应用程序返回的，还是反向代理服务器返回的。

假设你在纯服务器之间的API之间使用自定义HTTP返回码，你会发现开发者仅仅解析一个HTTP返回码是不够的，他们想知道错误的详细信息，这时候你还得返回一个json数据。当然上面说的反向代理的问题，在这里依然存在。

所以综上所述，我是不推荐使用自定义HTTP返回码的，虽然它很科学，但是它太学究，不实用。特别对于网站应用程序遇到链接找不到或者未捕获异常，才返回404或者500，而且返回的时候要使用友好的出错页来承载，其他逻辑错误也尽量使用错误页来承载。

422 Unprocesable entity - [POST/PUT/PATCH] 当创建一个对象时，发生一个验证错误。

感觉这个合适唉

422 Unprocesable entity - [POST/PUT/PATCH] 当创建一个对象时，发生一个验证错误。

这个提示也不错

有冲突信息的话也可以使用 409 Conflict

这边HTTP状态码解析可以看下
http://jingyan.baidu.com/arti...