更新和删除的http状态代码?

对于一个 放 请求: HTTP 200 或 HTTP 204 应该意味着“资源更新成功”。

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

9.6放

如果修改了现有资源,则应发送200(正常)或204(无内容)响应代码>,以指示请求已成功完成。

9.7删除

如果响应包含描述状态的实体,则成功响应应为200(正常),如果操作尚未执行,则为202(接受),如果操作已执行但响应不包含实体,则为204(无内容)。

来源: w3.org: HTTP/1.1 Method Definitions

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

HTTP 204无内容: 服务器已成功处理该请求,但未返回任何内容

来源: List of HTTP status codes: 2xx Success

简短回答:对于put和delete,您应该发送200(ok)或204(no content)。

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

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

以下是一些提示:

删除

• 二百 (如果要在响应中发送一些附加数据)或 二百零四 (推荐)。

• 二百零二 删除的操作尚未提交。

• 如果没有要删除的内容,请使用 二百零四 或 四百零四 (删除操作是等幂的,删除已删除的项是 操作成功 ,以便您可以返回 二百零四 ,但确实,等幂并不一定意味着相同的响应)

其他错误:

• 四百 不良要求 (语法不正确或查询错误 奇怪的 但有可能)。
• 四百零一 未经授权的 身份验证失败
• 四百零三 被禁止的 :授权失败或应用程序ID无效。
• 四百零五 不允许 . 当然。
• 四百零九 资源冲突 在复杂系统中是可能的。
• 和 五百零一 , 五百零二 以防出错。

放

如果要更新集合的元素

• 200/204 原因与上述删除相同。
• 二百零二 如果操作尚未提交。

引用的元素不存在:

• 放可以 二百零一 (如果您创建元素是因为这是您的行为)

• 四百零四 如果不想通过put创建元素。

• 四百 不良要求 (格式错误的语法或错误的查询比删除时更常见)。

• 四百零一 未经授权的
• 四百零三 被禁止的 :身份验证失败或应用程序ID无效。
• 四百零五 不允许 . 当然。
• 四百零九 资源冲突 在复杂的系统中是可能的,比如在delete中。
• 四百二十二 不可处理实体 它有助于区分“错误的请求”(例如格式错误的xml/json)和无效的字段值
• 和 五百零一 , 五百零二 以防出错。

RFC 2616描述 which status codes to use .

不,它是 不 总是200。

除了200和204, 205 (Reset Content) 可能是有效的响应。

服务器已完成请求,用户代理应重置导致发送请求的文档视图…[例如]清除输入的表格。

因为这个问题涉及到 删除 “应该”返回 二百 VS 二百零四 值得考虑的是,有些人建议返回带有链接的实体,因此首选 二百 .

“与返回204(没有内容)不同,api应该是有用的,并且 建议去哪里。在这个例子中,我认为 提供是为了“ 'somewhere.com/container/'(减去'resource') “-集装箱 客户端刚刚删除了一个资源。也许客户希望 删除更多资源,这样会是一个有用的链接。”

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

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

就个人而言,我不会说204是错的(作者也不会说204是错的;他说204是“烦人的”),因为在客户端进行良好的缓存有很多好处。最好的办法是保持一致。

2014年6月 RFC7231 废弃RFC2616。 如果你在http上做rest,那么 射频识别芯片 准确描述get、put、post和delete的预期行为

修改资源时,响应代码应为 200(好的) . 如果资源状态以将uri更改为资源的方式更改(例如,重命名用户帐户),则 响应代码是301(永久移动) 位置头应该提供新的uri。

删除对象时,响应代码 应该是200(好的)。

请按以下链接获取更多详细信息-- status code for rest