对已禁用资源的操作的预期 HTTP 状态代码

Posted

技术标签:

【中文标题】对已禁用资源的操作的预期 HTTP 状态代码【英文标题】:Expected HTTP status code for an action on a disabled resource 【发布时间】:2016-08-20 19:59:09 【问题描述】:

在给定以下条件的情况下,操作的预期/正确 HTTP 状态代码是什么:

请求语法正确(去掉400) 用户已通过身份验证(消除401) 用户被授权执行操作(消除403) 位置/资源存在(消除404) 方法已实现(消除501) 没有服务器错误(消除5xx

资源当前被禁用,因此无法完成预期结果的操作。用户可以更改资源的状态并重试相同的请求。有关资源为何无法执行所要求的操作的信息将包含在响应正文中。

我的想法是409 Conflict 将是最好的响应,因为用户可能会更改资源的状态并重新提交请求,但也许有更好的方法来表明 “您通常允许使用此方法,但资源当前处于无法按预期完成的状态。”

【问题讨论】:

您能否再解释一下资源“禁用”的方式?恕我直言 409 表示 presentation 中存在冲突,而这主要是关于 semantics 的讨论。 【参考方案1】:

409 似乎是最合适的,这就是 http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html 所说的:

仅在预期用户可能能够解决冲突并重新提交请求的情况下才允许使用此代码。响应正文应该包含足够的信息让用户识别冲突的来源。理想情况下,响应实体将包含足够的信息供用户或用户代理解决问题;但是,这可能是不可能的,也不是必需的。

【讨论】:

RFC2616 已过期。请参阅 RFC 7230-7235。 @EricStein 在 RFC 7230-7235 中有不同的代码还是仅供参考? @SamJakob 仅供参考。代码没有改变。【参考方案2】:

这似乎是互联网的共识,我没有看到更好的here。 See here for another similar question

409

此代码用于用户可能 能够解决冲突并重新提交请求。 Source

然后跟进

在响应 PUT 请求时最有可能发生冲突。为了 例如,如果正在使用版本控制并且表示是 PUT 包括对资源的更改,这些更改与由 较早的(第三方)请求

这似乎更像是在客户端构建调用时实体在客户端下方移动,也许假设是客户端在进行调用之前要求允许的操作。如果您实现了这一点,我会说 409 对您的 API 完全有效,因为您为客户端提供有效请求的能力,除非其他人更改实体。

显然,您应该保持一致,并记录响应代码及其用法。

【讨论】:

我认为 409 表示请求中的更改是必要的/可能的以使其成功。但是,在任何情况下都无法成功处理已停用的资源。认为 403 更适合 A 410 Gone 仍然很有趣,但正如定义所暗示的那样:“...表示对目标资源的访问在源服务器上不再可用,并且这种情况很可能是永久性的...如果您不知道这种情况是暂时的还是永久的,则应使用 404 状态码。” => developer.mozilla.org/en-US/docs/Web/HTTP/Status/410【参考方案3】:

根据 RFC 4918 (https://www.rfc-editor.org/rfc/rfc4918#section-11.2),您可以使用代码 422(不可处理实体)来处理类似的情况。

422 无法处理的实体

422(不可处理实体)状态码表示服务器 了解请求实体的内容类型(因此 a 415(不支持的媒体类型)状态码不合适), 请求实体的语法正确(因此为 400(错误请求) 状态码不合适)但无法处理包含的 指示。例如,如果 XML 请求正文包含格式正确(即语法正确),但 语义错误的 XML 指令。

【讨论】:

以上是关于对已禁用资源的操作的预期 HTTP 状态代码的主要内容,如果未能解决你的问题,请参考以下文章

HTTP 状态 403 - 未找到预期的 CSRF 令牌

HTTP协议结构

HTTP状态代码含义

http状态码

当端点被功能标记/功能切换禁用时,您使用什么HTTP状态代码?

如何将 AWS 漂移堆栈资源恢复到预期状态