我应该返回什么 HTTP 状态响应代码?

时间:2021-03-02 09:33:13

标签: api rest http http-status-codes

如果用户的 post 请求是正确的,但进程卡在决策(应该由客户端做出)的情况​​下,应该向用户发送什么 HTTP 状态代码,客户端应该再次调用相同的请求之一从应用发回新值以完成请求?

2 个答案:

答案 0 :(得分:0)

因此考虑到在这种情况下没有成功或失败,它肯定会丢弃 2xx、4xx 和 5xx 状态。我的观点是应该使用 300 Multiple Choices,这是 Wikipedia article on HTTP codes 的引用。

<块引用>

300 多项选择 指示客户端可以从中选择的资源的多个选项(通过代理驱动的内容协商)。例如,此代码可用于显示多种视频格式选项、列出具有不同文件扩展名的文件或建议词义消歧。[19]

在文章中,您可以找到有关客户如何在以下请求中选择其他选项的更多详细信息。

答案 1 :(得分:0)

有了这样的问题,这是开始了解 cache-invalidation 含义的好地方。

<块引用>

当收到非错误状态代码以响应不安全的请求方法时,缓存必须使有效的请求 URI 无效。

因此,返回 2xx 或 3xx 状态代码会通知通用客户端所有先前缓存的目标资源表示都应该无效。当返回 4xx 或 5xx 状态代码时,通用客户端将假定目标资源未更改。

因此:对于由于请求没有足够信息而导致文档未更改的情况,您需要一个 4xx 状态代码。对于文档已更改的情况(可能是某些“未完成”状态),您需要 2xx 状态代码。

在成功的情况下,您需要使用 200 Success 或 201 Created;选择取决于是否创建了新资源(例如,帮助客户完成编辑过程的新资源)。

对于不成功的情况,我建议422 Unprocessible Entity

<块引用>

422 (Unprocessable Entity) 状态码意味着服务器理解请求实体的内容类型(因此 415(不支持的媒体类型)状态码是不合适的),并且请求实体的语法是正确的(因此是 400 (错误请求)状态代码不合适)但无法处理包含的指令。例如,如果 XML 请求正文包含格式正确(即语法正确)但语义错误的 XML 指令,则可能会发生这种错误情况。