题 用于更新和删除的HTTP状态代码?


我应该为什么状态代码设置 UPDATE (PUT)和 DELETE (例如产品成功更新)?


994
2018-02-26 15:16


起源




答案:


为一个  请求: HTTP 200 要么 HTTP 204 应该意味着“资源更新成功”。

为一个 删除 请求: HTTP 200 要么 HTTP 204 应该意味着“资源被成功删除”。 HTTP 202 也可以返回,这意味着服务器接受了指令并且“资源被标记为删除”。

9.6 PUT

如果修改了现有资源,则应该发送200(OK)或204(No Content)响应代码>以指示请求成功完成。

9.7删除

如果响应包括描述状态的实体,则成功响应应为200(OK),如果操作尚未执行,则应为202(已接受);如果操作已颁布但响应不包括,则应为204(无内容)一个实体。

资源: w3.org:HTTP / 1.1方法定义

HTTP 200 OK: 成功HTTP的标准响应   要求。实际的反应会   取决于使用的请求方法。

HTTP 204没有内容: 服务器成功处理了请求,但未返回任何内容

资源: HTTP状态码列表:2xx成功


1545
2018-02-26 15:18



非常有用的帖子!但是我想知道HTTP状态代码应该是什么,客户端发送的请求是有效的(DELETE MYSITE /实体/ 123)并且要删除的实体不存在。 - Martin
@Martin:在这种情况下,服务应返回HTTP 404.严格地说,对不存在的资源的DELETE或GET请求是 不 一个“有效”的请求 - 即。客户端不应该重新尝试该请求,因为它永远不会成功... HTTP协议定义了两类问题 - 具有4xx状态代码的问题,客户端必须在重试之前修改请求,以及具有5xx状态的问题代码,表明服务遇到了麻烦,客户端应该/可以重试相同的确切请求而不更改它。 - Daniel Vassallo
@JeffMartin从用户的角度来看可能是这样,但就服务器而言,如果资源不存在,服务器应该返回404。 - Randolpho
@Randolpho,无论是一次还是多次调用一次操作,Idempotence都是为了获得相同的结果。客户端要求您确保删除资源。返回404有什么好处?为什么它需要知道哪种方式?现在,客户端逻辑必须处理两个单独的响应代码而不是一个。 - Gili
@Gili:也许吧 维基 会更好地解释: 方法PUT和DELETE被定义为幂等...请注意,幂等性是指请求完成后系统的状态,因此当服务器采取的操作(例如删除记录)或它返回的响应代码可能不同时在后续请求中,系统状态每次都是相同的。 - Randolpho


简答:对于PUT和DELETE,您应该发送200(OK)或204(No Content)。

答案很长:这是一个完整的决策图(点击放大)。

HTTP 1.1 decision diagram

资源: https://github.com/for-GET/http-decision-diagram


718
2018-02-26 15:23



这个图很棒。是否有更高分辨率的打印版本? - KiKi
我很好奇是否应该撤消删除后的204和200响应,如果它们是正确的,为什么呢?删除吗? - >响应包括一个实体? - >是 - > 204没有内容;不 - > 200 OK - matth
图像的更新版本在这里: raw.github.com/for-GET/http-decision-diagram/master/httpdd.png - zaius
它缺少PATCH。 - doremi
@unomi github.com/for-GET/http-decision-diagram - zaius


以下是一些提示:

删除

  • 200 (如果你想在响应中发送一些额外的数据)或 204 (推荐的)。

  • 202 已删除的操作尚未提交。

  • 如果没有要删除的内容,请使用 204  要么  404 (DELETE操作是幂等的,删除已删除的项目是 操作成功,所以你可以回来 204,但幂等并不一定意味着同样的反应)

其他错误:

  • 400  错误的请求 (格式错误的语法或错误的查询是 奇怪 但可能)。
  • 401  擅自 验证失败
  • 403  被禁止:授权失败或无效的应用程序ID。
  • 405  不允许。当然。
  • 409  资源冲突 在复杂的系统中是可能的。
  • 501502 如果有错误。

如果您要更新集合的元素

  • 200/204 与上面的DELETE相同的原因。
  • 202 如果尚未提交操作。

引用的元素不存在:

  • PUT可以 201 (如果你创建了元素,因为这是你的行为)
  • 404 如果您不想通过PUT创建元素。

  • 400  错误的请求 (格式错误的语法或错误的查询比DELETE的情况更常见)。

  • 401  擅自 
  • 403  被禁止:身份验证失败或应用程序ID无效。
  • 405  不允许。当然。
  • 409  资源冲突 在DELETE中可以在复杂系统中实现。
  • 422  不可处理的实体 它有助于区分“错误请求”(例如格式错误的XML / JSON)和无效字段值
  • 501502 如果有错误。

105
2017-09-24 12:14



这个答案几乎完全由两个大引号组成,但没有归属。你在哪里引用? - Quentin
如果状态未有效更改,则204是否为PUT请求返回正确状态?例如,您要求停用用户但该用户已处于非活动状态。 - Ε Г И І И О
PUT请求是幂等的,因此您可以返回204,因为该对象 已经改变 在系统中。 PUT不是PATCH,因此您不确定要更改哪个字段。如果您的设计需要知道对象是否存在,您可以发回501 - 502 究竟 与请求中的对象相同但是...我真的不喜欢它..我更喜欢204或者,如果你想停用一个用户,而不需要更改更多的字段,也许你可以使用PATCH。 - Alfonso Tienda
我将添加HTTP 422 Unprocessable Entity。它有助于区分“错误请求”(例如格式错误的XML / JSON)和无效字段值。 - vdboor
好吧,谢谢 - Alfonso Tienda


RFC 2616描述 要使用哪些状态代码

不,这是  总是200。


13
2018-02-26 15:20





除了200和204, 205(重置内容) 可能是一个有效的回应。

服务器已经完成了请求,并且用户代理应该重置文档视图,该文档视图导致请求被发送... [例如]清除给出输入的表单。


7
2018-01-08 21:15





因为这个问题深入研究了 删除 “应该”回归 200 VS 204 值得考虑的是,有些人建议返回一个带有链接的实体,以便优先选择 200

“而不是返回204(无内容),API应该是有用的   建议去的地方。在这个例子中,我认为有一个明显的链接   提供是“ 'somewhere.com/container/'(减去'资源') “ - 从哪个容器   客户端刚刚删除了一个资源。也许客户希望   删除更多资源,这将是一个有用的链接。“

http://blog.ploeh.dk/2013/04/30/rest-lesson-learned-avoid-204-responses/

如果客户遇到204响应,它可以放弃,转到   API的入口点,或者回到之前的资源吧   参观。这两种选择都不是特别好。

我个人不会说204是错的(作者也没有;他说“讨厌”)因为客户端的良好缓存有很多好处。最好的方法是保持一致。


6
2018-05-29 02:02





2014年6月 RFC7231 废弃RFC2616。 如果您正在通过HTTP进行REST RFC7231 准确描述了GET,PUT,POST和DELETE的预期行为


2
2017-11-22 15:52





修改资源时,应该是响应代码 200(“OK”)。如果资源状态以更改URI到资源的方式更改(例如,重命名用户帐户),则 响应代码为301(“永久移动”) 并且Location标头应该提供新的URI。

删除对象时,响应代码 应该是200(“OK”)。

请点击以下链接了解更多详情 - 休息的状态代码


0
2017-12-26 07:51