假设我有一个可以获取用户的API：
GET /RESTAPI/user/
您可以通过以下方式删除用户：
DELETE /RESTAPI/user/123
关于DELETE的响应主体应包含的RESTful约定是什么？我希望它应该是所有用户的新列表，现在不再包含ID为123的用户。
谷歌搜索并没有给我任何令人满意的答案。我只找到有关如何执行此操作的意见，但是对RESTful服务没有严格的定义吗？
这与RESTful API POST / DELETE应该在主体中返回什么不重复？以及约定应返回哪些REST PUT / POST / DELETE调用？ 因为此问题要求对DELETE进行严格定义。这些问题仅由宽松的意见回答。
Answers:
之所以没有硬性答案，是因为没有硬性的RESTful标准。因此，我只能建议您创建一个硬标准并在您自己的API中坚持使用
我将其用作RESTful服务的指南http://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api
它说以204状态和空着的身体回应
我遵守这些标准，并为想要使用我的API的任何人很好地记录在案
关于REST
DELETE主体应包含哪些RESTful约定？
REST是Fielding在其论文的第5章中定义的一种体系结构样式，它描述了使用此体系结构构建的应用程序的一系列约束。REST被设计为与协议无关，但是同一论文的第6章介绍了如何在HTTP上应用REST。
将REST应用程序设计在HTTP协议的顶部之后，您应该了解HTTP语义。目前，RFC 7231中描述了HTTP / 1.1协议的语义。
DELETE成功的请求的响应有效负载可能是：
并且以下响应状态代码适用于DELETE成功的请求：
请参阅RFC 7231中的以下引用：
如果
DELETE成功应用了方法，则202如果动作可能成功但尚未执行，则源服务器应发送（接受）状态代码；如果204动作已执行且没有更多信息可发送，则发送（无内容）状态代码。200（如果已执行操作，并且响应消息中包含描述状态的表示形式，则提供（OK）状态代码）。
204 No Content是一个受欢迎的回应DELETE，偶尔PUT也是如此。
但是，如果要实现HATEOAS，则返回200 OK带有链接的a可能更理想。这是因为HATEOAS REST API为客户端提供了上下文。想一想用户应用程序在成功发出删除命令后导航到的位置。这是一个简短的文章摘录，对此有更多讨论。有关更完整的讨论，请参见博客文章。
如果要构建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”标签，但另一种查看方式是/ rock资源包含在标签容器中（它本身是一个资源）。Atom Pub用户应该熟悉它。
假设您要删除http://foo.ploeh.dk/api/tags/rock资源。为了实现该目标，您可以针对它发出DELETE请求。如果所有的客户端回来是204（无内容），它只是失去了它的背景。它从那里去哪里？除非您保持对客户端的状态，否则您将不知道自己来自何方。
API不应返回204（无内容），而是应该会有所帮助并建议要去的地方。在此示例中，我认为要提供的一个明显链接是http://foo.ploeh.dk/api/tags-客户端刚刚从中删除资源的容器。客户端可能希望删除更多资源，因此这将是一个有用的链接。