假设我有一个可以获取用户的 API：
GET /RESTAPI/user/
您可以通过以下方式删除用户：
DELETE /RESTAPI/user/123
关于 DELETE 的响应正文应包含什么的 RESTful 约定是什么？ 我预计它应该是所有用户的新列表，现在不再包含 id 为 123 的用户。
谷歌搜索并没有得到任何令人满意的答案。我只找到了关于如何做到这一点的意见，但是 RESTful 服务没有严格的定义吗？
这不是 What should a RESTful API POST/DELETE return in the body? 和 What REST PUT/POST/DELETE calls should return by a convention? 的副本 因为这个问题要求对 DELETE 进行严格定义。这些问题只能由松散的意见来回答。
【问题讨论】：
标签： rest http restful-url
您没有得到硬性答案的原因是没有硬性的 RESTful 标准。所以我只能建议你创建一个硬标准并在你自己的 API 中坚持它
我将此用作 RESTful 服务的指南http://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api
它表示以 204 状态和空正文响应
我坚持这些标准并为任何想要使用我的 API 的人详细记录它们
【讨论】：
关于
DELETE的响应正文应包含什么的RESTful 约定是什么？
REST 是 Fielding 在他的论文chapter 5 中定义的一种架构风格，它描述了使用这种架构构建的应用程序的一组约束。 REST 被设计为独立于协议的，但同一篇论文的chapter 6 描述了如何通过 HTTP 应用 REST。
一旦您的 REST 应用程序是在 HTTP 协议之上设计的，您就应该了解 HTTP 语义。而HTTP/1.1协议的语义目前描述在RFC 7231。
已成功的DELETE 请求的响应负载可能：
以下响应状态码适用于已成功的DELETE 请求：
请参阅RFC 7231 中的以下引用：
如果
DELETE方法成功应用，源服务器应该 如果操作可能成功，则发送202（已接受）状态代码 但尚未制定，204（无内容）状态代码，如果 已采取行动，无需提供进一步的信息， 或200(OK) 状态码（如果已执行该操作且 响应消息包括描述状态的表示。
【讨论】：
204 No Content 是DELETE 的热门回复，偶尔PUT 也是如此。
但是，如果您正在实施 HATEOAS，则返回带有链接的 200 OK 可能更理想。这是因为 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 资源包含在 tags 容器中（它本身就是一个资源）。这对于 Atom Pub 用户来说应该很熟悉。
假设您要删除http://foo.ploeh.dk/api/tags/rock 资源。为了实现该目标，您针对它发出 DELETE 请求。如果您的客户返回的所有内容都是 204（无内容），那么它只是失去了它的上下文。它从那里去哪里？除非你在客户端上保持状态，否则你不知道你来自哪里。
API 应该会有所帮助并建议去哪里，而不是返回 204（无内容）。在此示例中，我认为要提供的一个明显链接是 http://foo.ploeh.dk/api/tags - 客户端刚刚从中删除资源的容器。也许客户希望删除更多资源，所以这将是一个有用的链接。
【讨论】：
DELETE 和 HATEOAS 的问题实际上取决于人们希望如何实现 HATEOAS。如果 HATEOAS 实现涉及服务器返回嵌入在消息正文中的链接关系（即HAL 或json-ld），那么204 No content 可能不是最洁净的状态代码。但是，如果 HATEOAS 实现在响应标头中有服务器返回链接关系（即web linking），那么204 No content 就完全符合要求。