RESTful - DELETE响应主体应包含什么

Question

假设我有一个API,您可以在其中获取用户:

GET /RESTAPI/user/

您可以通过以下方式删除用户:

DELETE /RESTAPI/user/123

关于DELETE的响应主体应该包含什么是RESTful约定？我希望它应该是所有用户的新列表,现在不再包含id为123的用户.

谷歌搜索没有给我任何令人满意的答案.我只发现了如何做到这一点的意见,但是没有RESTful服务的严格定义？

这不是RESTful API POST/DELETE在正文中返回什么的重复？和什么REST PUT/POST/DELETE调用应由公约回报？ 因为这个问题要求对DELETE有严格的定义.这些问题只能通过松散的意见来回答.

Answer 1

你没有得到硬答案的原因是因为没有硬的RESTful标准.因此,我只能建议您创建一个硬标准,并在自己的API中坚持下去

我使用它作为RESTful服务的指南http://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api

它表示回复204状态和空身

我坚持使用这些标准并将其记录在任何想要使用我的API的人身上

Answer 2

204 No Content是一种流行的反应DELETE,偶尔PUT也是如此.

但是,如果您正在实施HATEOAS,则返回200 OK带有以下链接的链接可能更为理想.这是因为HATEOAS REST API为客户端提供了上下文.在成功发出删除命令后,可以考虑用户应用程序导航到的位置.这是一篇简短的文章摘录,对此有更多的讨论.有关更完整的讨论,请参阅博客文章.

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

如果您正在构建HATEOAS应用程序,请避免204个响应.

这是我在构建非平凡REST API时学到的REST API设计课程.为了尽可能支持客户端,REST API不应返回204(无内容)响应.

从服务的角度来看,204(无内容)响应可能是对POST,PUT或DELETE请求的完全有效的响应.特别是,对于DELETE请求似乎非常合适,因为您还能说什么呢？

但是,从适当的HATEOAS感知客户端的角度来看,204响应是有问题的,因为没有要遵循的链接.当超媒体充当应用程序状态的引擎时,当没有链接时,就没有状态.换句话说,204响应抛弃所有应用程序状态.

本文介绍了POST,PUT,DELETE和GET.以下是对具体讨论DELETE:

响应DELETE请求

DELETE请求表示删除资源的意图.因此,如果服务成功处理DELETE请求,那么还能做什么比返回204(无内容)？毕竟,资源刚被删除.

资源通常是集合的成员,或者由容器"拥有".例如,http://foo.ploeh.dk/api/tags/rock代表一个"摇滚"标签,但另一种看待它的方式是/ rock资源包含在标签容器中(它本身就是一个资源).这应该是Atom Pub用户所熟悉的.

想象一下,您想要删除http://foo.ploeh.dk/api/tags/rock资源.为了实现该目标,您可以针对它发出DELETE请求.如果你的所有客户都回来了204(没有内容),它就会失去它的背景.它从哪里去？除非你在客户端保持状态,否则你不知道你来自哪里.

API不应该返回204(无内容),而应该提供帮助并建议去的地方.在这个例子中,我认为提供的一个明显的链接是http://foo.ploeh.dk/api/tags - 客户端刚从中删除资源的容器.也许客户希望删除更多资源,这将是一个有用的链接.

Answer 3

关于RESTDELETE主体应包含哪些RESTful约定？

REST是Fielding在其论文的第5章中定义的一种体系结构样式，它描述了使用该体系结构构建的应用程序的一系列矛盾。REST被设计为与协议无关，但是同一论文的第6章介绍了如何在HTTP上应用REST。

将REST应用程序设计在HTTP协议的顶部之后，您应该了解HTTP语义。目前，RFC 7231中描述了HTTP / 1.1协议的语义。

DELETE成功的请求的响应有效负载可能是：

• 为空或
• 包括动作状态的表示。

并且以下响应状态代码适用于DELETE成功的请求：

• 202：该请求已被接受进行处理，但是处理尚未完成。
• 204：服务器已成功满足请求，并且响应有效内容正文中没有其他要发送的内容。
• 200：请求已成功完成，请求有效负载包括操作状态的表示。

请参阅RFC 7231中的以下引用：

如果DELETE成功应用了一种方法，则202如果该动作可能成功但尚未执行，则源服务器应发送（接受）状态码；如果该动作204已经执行且没有更多信息可发送，则发送（无内容）状态码。或提供200（OK）状态代码（如果已执行操作并且响应消息包含描述状态的表示）。