这是一个创建于 2845 天前的主题，其中的信息可能已经有所发展或是发生改变。
-
如果请求体的格式错误，比如使用了格式错误的 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-02-01 18:02:54 +08:00
已经得到想要的答案。谢谢大家伙儿。
 |
1
jybox 2017-02-01 16:24:00 +08:00  1
可供参考：
422 Unprocessable Entity 语义错误，适用大部分客户端错误的情况 409 Conflict 冲突，适用需要用户解决冲突并重新提交的情况（用户名已被使用） 其实除了一些非常常见的错误代码，其他的错误代码大家都没有很明确的共识，所以死扣哪个代码更合理意义并不大。 |
 |
2
FrankFang128 2017-02-01 16:25:48 +08:00 1
我理解 400 是一个通用错误，如果你不确定用 4 几几，那就 400 吧
|
 |
3
mornlight 2017-02-01 16:38:07 +08:00 1
看具体的原因，对于用户名冲突来说可以报 409 。用户名字符不符合规范可以用 400 。
|
 |
4
tonyluj 2017-02-01 16:49:58 +08:00 1
对于比较模糊或者模棱两可的请求错误，可以使用广义的 400 来表示这种错误，在 Response 的 `message` 字段中注明详细错误，同时在 API 文档中解释清楚
对于楼主提到的，可以使用 422 Unprocessable Entity ，一楼已经给出了详细解释 |
 |
5
haozhang 2017-02-01 18:21:16 +08:00 via iPhone 1
你可以把错误简单分为 301 ， 400 ， 500 然后返回的 json 加个自定义的 error code ，类似： error_code ：“ a200 ”， a200 表示某某错误， a201 表示某某错误
|
 |
6
lslqtz 2017-02-02 07:28:16 +08:00 via iPhone 1
我喜欢直接抛 403+json 提供错误码
|
 |
7
franklinyu 2017-02-02 10:13:05 +08:00 1
對於這種情況我個人習慣 422
|
Select Language