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

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

对于PUT请求: HTTP 200HTTP 204应该暗示“资源更新成功”。

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

9.6 PUT

如果现有资源被修改,则应该发送200(OK)或204(无内容)响应代码来指示成功完成请求。

9.7删除

如果响应包括描述状态的实体,则成功的响应应该是200(OK),如果该操作尚未实施,则成功响应202(接受),如果该操作已经被实施,则响应不包括204(无内容)一个实体。

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

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

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

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

简短的回答:对于PUT和DELETE,您应该发送200(OK)或204(无内容)。

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

HTTP 1.1决定图

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

这里有一些提示:

删除

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

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

  • 如果没有东西需要删除,使用204 404 (DELETE操作是幂等的,删除一个已经删除的项目是操作成功的 ,所以你可以返回204 ,但是幂等不一定意味着相同的响应)

其他错误:

  • 400 错误的请求 (格式错误或错误的查询很奇怪,但可能)。
  • 401 未经授权的身份validation失败
  • 403 禁止 :授权失败或无效的应用程序ID。
  • 405 不允许 。 当然。
  • 在复杂的系统中可能会出现资源冲突
  • 501,502如有错误。

如果您正在更新集合的元素

  • 200/204 ,原因与上面的DELETE相同。
  • 202如果操作还没有被提交。

引用的元素不存在:

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

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

  • 401 未经授权
  • 403 禁止 :authentication失败或无效的应用程序ID。
  • 405 不允许 。 当然。
  • 在DELETE中,复杂系统中可能会出现资源冲突
  • 501,502如有错误。

RFC 2616描述了要使用的状态码 。

不, 总是200。

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

服务器已经完成了请求,用户代理应该重置导致请求被发送的文档视图… [例如]清除input的forms。

由于这个问题深入研究,如果DELETE “应该”返回200204 ,值得考虑的是有些人build议返回一个实体的链接,所以首选为200

在这个例子中,我认为一个显而易见的链接是“ somewhere.com/container/”(减去“资源”) -客户端刚刚删除了一个资源的容器,也许客户端希望删除更多的资源,这将是一个有用的链接。

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

如果客户端遇到204响应,则可以放弃,进入API的入口点,或返回到它所访问的前一个资源。 这两个选项都不是特别好。

就个人而言,我不会说204是错的(作者也没有,他说“烦人”),因为客户端的好caching有很多好处。 最好的是要保持一致。

RFC7231在2014年6月废止 RFC2616。 如果您通过HTTP进行REST,则RFC7231会准确描述GET,PUT,POST和DELETE的行为