这是一个创建于 3293 天前的主题，其中的信息可能已经有所发展或是发生改变。
-
如果请求体的格式错误，比如使用了格式错误的 JSON ，这时，应该使用状态码 400
-
如果请求体的格式正确，但是其中的某个字段所包含数据由于业务逻辑而不能被使用时，比如不能使用已经存在的用户名，这时的状态码应该使用什么呢？
400: The server cannot or will not process the request due to something that is perceived to be a client error (e.g., malformed request syntax, invalid request message framing, or deceptive request routing).
403: The server understood the request but refuses to authorize it.
疑惑点在：这种出于业务逻辑的原因而不能使用某个字段所包含的数据的情况，应该被归类于请求格式错误(400)，还是拒绝响应(403)呢？
第 1 条附言 2017 年 2 月 1 日
已经得到想要的答案。谢谢大家伙儿。
 | 1 jybox 2017 年 2 月 1 日  1 可供参考： 422 Unprocessable Entity 语义错误，适用大部分客户端错误的情况 409 Conflict 冲突，适用需要用户解决冲突并重新提交的情况（用户名已被使用） 其实除了一些非常常见的错误代码，其他的错误代码大家都没有很明确的共识，所以死扣哪个代码更合理意义并不大。 |
 | 2 FrankFang128 2017 年 2 月 1 日 1 我理解 400 是一个通用错误，如果你不确定用 4 几几，那就 400 吧 |
 | 3 mornlight 2017 年 2 月 1 日 1 看具体的原因，对于用户名冲突来说可以报 409 。用户名字符不符合规范可以用 400 。 |
 | 4 tonyluj 2017 年 2 月 1 日 1 对于比较模糊或者模棱两可的请求错误，可以使用广义的 400 来表示这种错误，在 Response 的 `message` 字段中注明详细错误，同时在 API 文档中解释清楚 对于楼主提到的，可以使用 422 Unprocessable Entity ，一楼已经给出了详细解释 |
Select Language