请教：关于 RESTful API 中状态码的疑惑

[m31271n]

1. 如果请求体的格式错误，比如使用了格式错误的 JSON ，这时，应该使用状态码 400

2. 如果请求体的格式正确，但是其中的某个字段所包含数据由于业务逻辑而不能被使用时，比如不能使用已经存在的用户名，这时的状态码应该使用什么呢？

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)呢？

[jybox]

可供参考：

422 Unprocessable Entity 语义错误，适用大部分客户端错误的情况
409 Conflict 冲突，适用需要用户解决冲突并重新提交的情况（用户名已被使用）

其实除了一些非常常见的错误代码，其他的错误代码大家都没有很明确的共识，所以死扣哪个代码更合理意义并不大。

[FrankFang128]

我理解 400 是一个通用错误，如果你不确定用 4 几几，那就 400 吧

[mornlight]

看具体的原因，对于用户名冲突来说可以报 409 。用户名字符不符合规范可以用 400 。

[tonyluj]

对于比较模糊或者模棱两可的请求错误，可以使用广义的 400 来表示这种错误，在 Response 的 `message` 字段中注明详细错误，同时在 API 文档中解释清楚

对于楼主提到的，可以使用 422 Unprocessable Entity ，一楼已经给出了详细解释

[haozhang]

你可以把错误简单分为 301 ， 400 ， 500 然后返回的 json 加个自定义的 error code ，类似： error_code ：“ a200 ”， a200 表示某某错误， a201 表示某某错误

[lslqtz]

我喜欢直接抛 403+json 提供错误码

[franklinyu]

對於這種情況我個人習慣 422