返回带有 REST DELETE 的正文答案

【问题标题】：Return a body with a REST DELETE返回带有 REST DELETE 的正文
【发布时间】：2014-08-10 18:15:19
【问题描述】：

我正在实现一个用于设置和检索资源的 REST api。

我最初的实现非常简单：

1) PUT - path 指定要存储的 {id}，请求正文是要存储的 JSON 对象，成功时返回 200 响应

2) GET - 路径指定要检索的 {id}，请求正文为空，返回 200 响应和正文中存储的 JSON 对象

3) DELETE - 路径指定要删除的 {id}，请求正文为空，返回 200 和空正文（是的，可能应该是 204）

但是，一个比我更有影响力的上游方要求我们对 JSON 对象进行破坏性检索。他们坚持认为，他们不想费心进行单独的 GET 和 DELETE 调用（即，这与试图确保原子调用以消除竞争条件的人无关）。

对我来说，这似乎违反了 RESTful 服务的精神，当我尝试记录此更改时，API 文档有一种明确的“代码气味”，因为在尝试清楚地记录 GET/DELETE 方法时感觉很尴尬.

显然，我可以实现任何可行的方法，但是是否存在关于破坏性读取的完善约定？在某些情况下确实需要原子调用吗？

【问题讨论】：

标签： rest http

【解决方案1】：

他们所要求的与 REST 无关，但它与 HTTP RFC (#7231) 相违背。

如果成功应用 DELETE 方法，则源服务器如果操作可能会发送 202（已接受）状态代码成功但尚未制定，204（无内容）状态代码，如果行动已经制定并且没有进一步的信息提供，或 200 (OK) 状态码（如果操作已完成）制定并且响应消息包括表示描述状态。

这很清楚。你可以返回一个200 (Ok)，但是响应中的实体应该是一个状态对象，而不是被删除的对象。当然，无论如何，你可能会被欺负，办公室政治就是这样。询问他们为什么需要违反 RFC 的经过验证的技术原因。不要接受“太贵了”的手忙脚乱的说法——让他们提供实际的测试用例来证明存在问题。

我知道原子读取/删除操作没有定义的语义。如果没有更多信息，很难就如何继续向您提供建议，这可能超出了本网站的范围。

【讨论】：