Dan*_*llo 1946
对于PUT请求:HTTP 200或HTTP 204应该意味着"资源更新成功".
对于DELETE请求:HTTP 200或HTTP 204应表示"资源已成功删除".还可以返回HTTP 202,这意味着服务器接受该指令并且"资源被标记为删除".
9.6 PUT
如果修改了现有资源,则应该发送200(OK)或204(No Content)响应代码>以指示请求成功完成.
9.7删除
如果响应包括描述状态的实体,则成功响应应为200(OK),如果操作尚未执行,则应为202(已接受);如果操作已颁布但响应不包括,则应为204(无内容)一个实体.
HTTP 200 OK:成功HTTP请求的标准响应.实际响应取决于使用的请求方法.
HTTP 204 No Content:服务器成功处理了请求,但未返回任何内容
- @Martin:在这种情况下,服务应返回HTTP 404.严格来说,对不存在的资源的DELETE或GET请求不是**"有效"请求 - 即.客户端不应该重新尝试该请求,因为它永远不会成功... HTTP协议定义了两类问题 - 具有4xx状态代码的问题,客户端必须在重试之前修改请求,以及具有5xx状态的问题代码,表明服务遇到了麻烦,客户端应该/可以重试相同的确切请求而不更改它. (57认同)
- 非常有用的帖子!但是我想知道HTTP状态代码应该是什么,客户端发送的请求是有效的(DELETE http:// mySite/entity/123),并且要删除的实体不存在. (37认同)
- @Gili:也许[wiki](http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol#Idempotent_methods_and_web_applications)会更好地解释:*方法PUT和DELETE被定义为幂等...注意幂等性指的是状态在请求完成后系统,所以当服务器采取的动作(例如删除记录)或它返回的响应代码在后续请求中可能不同时,系统状态每次都是相同的.* (24认同)
- @JeffMartin从用户的角度来看可能是这样,但就服务器而言,如果资源不存在,服务器应该返回404. (17认同)
- @Randolpho,无论是一次还是多次调用一次操作,Idempotence都是为了获得相同的结果.客户端要求您确保删除资源.返回404有什么好处？为什么它需要知道哪种方式？现在客户端逻辑必须处理两个单独的响应代码而不是一个. (17认同)
- @Martin,Daniel我想你正在研究DELETE的成功召唤.如果将DELETE视为"确保资源被删除",那么无论资源是否存在,它都会成功. (7认同)
- @Randolpho,如果你的用户想要检查资源的存在,它应该使用`GET`或`If-Match`标题.我的理解是"DELETE"等同于Linux上的`rm`:删除文件(如果存在),否则什么都不做."DELETE"失败的唯一时间是资源是否存在但由于某种原因无法删除(例如,您没有足够的权限). (7认同)
- @Gili,你的意思是Linux上的`rm -f`？如果文件不存在,`rm`会给你一个错误. (5认同)
- @Gili我不确定我理解这个问题.404具有特定含义:请求很糟糕,因为资源不存在.允许成功代码会让客户错误地认为资源*确实存在并被删除.并且如果客户希望成为一个健壮且不容易出错的客户端,那么客户肯定会更好地处理所有*可能的响应代码. (4认同)
- 为什么不谈论PUT(更新)的"205重置内容"？ (3认同)
- Ceph返回201以使用PUT成功创建。 (2认同)
- DanielVassallo，@ Randolpho，我不同意。使用PUT或DELETE，客户端正在请求服务器上存在某种状态。DELETE与删除无关，而是“我希望此资源不存在”。服务器收到2xx响应，通知客户端其请求已成功，状态已达到。通过发送404，您正在“重载”状态代码，以通知客户端有关服务器在请求之前的状态是什么，以及服务器为达到该状态必须要做的事情。如果它对您的特定业务案例有帮助，那就去做，但是2xx更正确。 (2认同)
Яeg*_*ght 820
简短回答:对于PUT和DELETE,您应该发送200(OK)或204(No Content).
答案很长:这是一个完整的决策图(点击放大).
资料来源:https://github.com/for-GET/http-decision-diagram
- 该图像的更新版本在这里:https://raw.github.com/for-GET/http-decision-diagram/master/httpdd.png (60认同)
- 这个图很棒.是否有更高分辨率的打印版本？ (36认同)
- 它缺少PATCH. (17认同)
- 我很好奇是否应该撤消删除后的204和200响应,如果它们是正确的,为什么呢？删除吗？ - >响应包括一个实体？ - >是 - > 204没有内容; 不 - > 200 OK (7认同)
- @docksteaderluke 很棒的东西，但为什么那里没有 POST 代码？ (2认同)
Alf*_*nda 138
以下是一些提示:
删除
200(如果您想在响应中发送一些额外的数据)或204(推荐).
202已删除的操作尚未提交.
如果没有要删除的内容,请使用204 或 404(DELETE操作是幂等的,删除已删除的项目操作成功,因此您可以返回204,但是幂等并不一定意味着相同的响应)
其他错误:
- 400 Bad Request(格式错误的语法或错误的查询很奇怪,但可能).
- 401 未授权的身份验证失败
- 403 禁止访问:授权失败或应用程序ID无效.
- 405 不允许.当然.
- 409 在复杂系统中可以实现资源冲突.
- 而501,502在错误的情况下.
放
如果您要更新集合的元素
- 200/204与上述DELETE相同的原因.
- 202如果尚未提交操作.
引用的元素不存在:
- PUT可以是201(如果你创建了元素,因为这是你的行为)
404如果您不想通过PUT创建元素.
400 Bad Request(格式错误的语法或错误的查询比DELETE的情况更常见).
- 401 未经授权
- 403 Forbidden:身份验证失败或应用程序ID无效.
- 405 不允许.当然.
- 409 在复杂系统中可以实现资源冲突,如DELETE中那样.
- 422 不可处理的实体它有助于区分"错误请求"(例如格式错误的XML/JSON)和无效字段值
- 而501,502在错误的情况下.
- 这个答案几乎完全由两个大引号组成,但没有归属.你在哪里引用？ (5认同)
这是一些状态代码，你应该知道你的知识。
1XX 信息响应
- 100 继续
- 101 交换协议
- 102 处理
- 103 早期提示
2XX 成功
- 200 正常
- 201 创建
- 202 接受
- 203 非权威信息
- 204 无内容
- 205 重置内容
- 206 部分内容
- 207 多状态
- 208 已举报
- 226 IM使用
3XX 重定向
- 300 多项选择
- 301 永久搬家
- 302 发现
- 303 看其他
- 304 未修改
- 305 使用代理
- 306 切换代理
- 307 临时重定向
- 308 永久重定向
4XX 客户端错误
- 400 错误请求
- 401 未授权
- 402 需要付款
- 403 禁地
- 404 未找到
- 405 方法不允许
- 406 不可接受
- 407 需要 代理认证
- 408 请求超时
- 409 冲突
- 410 飘
- 411 所需长度
- 412 前置条件失败
- 413 负载过大
- 414 URI太长
- 415 不支持的媒体类型
- 416 范围不满足
- 第417章 期待落空
- 第418章 我是茶壶
- 420 方法失败
- 421 错误的 请求
- 422 无法处理的实体
- 423 锁定
- 424 依赖失败
- 426 需要升级
- 428 需要先决条件
- 429 请求过多
- 431 请求头字段太大
- 451 因 法律原因不可用
5XX 服务器错误
- 500 内部服务器错误
- 501 未实施
- 502 坏网关
- 503 服务不可用
- 504 网关超时
- 505 不支持 Http 版本
- 506 变种 也商量
- 507 存储空间不足
- 508 检测到环路
- 510 未扩展
- 511 需要 网络认证
由于问题深入研究DELETE "应该"返回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错了(作者也没有;他说"讨厌")因为客户端的良好缓存有很多好处.最好的方法是保持一致.