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

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

GET /RESTAPI/user/

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

DELETE /RESTAPI/user/123

DELETE 的响应主体应该包含哪些内容的 宁静的约定是什么？ 我希望它应该是所有用户的新列表，现在不再包含 id 为123的用户。

上网搜索并没有得到满意的答案。我只找到了关于如何做的意见，但是 RESTful 服务不是有一个严格的定义吗？

这不是 RESTful API POST/DELETE 应该在主体中返回什么？和 < a href = “ https://stackoverflow./questions/4268707/What-REST-PUT-POST-DELETE-call-should-return-by-a-Convention”> 什么 REST PUT/POST/DELETE 调用应该按照约定返回？ 因为这个问题需要一个关于 DELETE 的严格的定义。这些问题只能通过宽松的意见来回答。

123294 次浏览
小开
最佳答案

之所以没有硬性的答案，是因为没有硬性的 RESTful 标准。因此，我只能建议您创建一个硬标准，并在自己的 API 中坚持它

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

上面写着204状态和一具空尸体

我坚持这些标准，并为任何想要使用我的 API 的人很好地记录它们

小开

204 No Content是 DELETE和偶尔 PUT的流行反应。

但是，如果您正在实现 HATEOAS，那么返回一个带有链接的 200 OK可能更为理想。这是因为 HATEOASRESTAPI 为客户机提供上下文。考虑用户应用程序在成功发出 delete 命令后导航到的位置。下面是一篇简短的文章摘录，对此进行了更多的讨论。有关更完整的讨论，请参阅博客文章。

如果您正在构建 HATEOAS 应用程序，请避免使用204个响应。

这是我在构建重要的 RESTAPI 时学到的有关 RESTAPI 设计的一课。为了尽可能支持客户端，REST API 不应该返回204(No Content)响应。

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

然而，从适当的 HATEOAS 感知客户端的角度来看，204响应是有问题的，因为没有可以跟踪的链接。当超媒体充当应用程序状态的引擎时，当没有链接时，就没有状态。换句话说，204响应抛弃了所有应用程序状态。

这篇文章涵盖了 POST，PUT，DELETE和 GET。下面是关于 DELETE的具体讨论:

响应删除请求

DELETE 请求表示删除资源的意图。因此，如果服务成功地处理了 DELETE 请求，除了返回204(No Content)之外，它还能做什么？毕竟，资源刚刚被删除。

资源通常是集合的成员，或者由容器“拥有”。例如，http://foo.ploeh.dk/api/tags/rock表示一个“ rock”标记，但是从另一个角度来看,/rock 资源包含在标记容器中(它本身就是一个资源)。Atom Pub 用户应该对此很熟悉。

假设您想删除 http://foo.ploeh.dk/api/tags/rock资源。为了实现这个目标，需要对其发出 DELETE 请求。如果您的客户端得到的只是一个204(无内容) ，它只是失去了它的上下文。然后呢？除非你对客户保密，否则你不知道自己来自哪里。

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

小开

DELETE的响应主体应该包含什么样的 宁静的约定？

REST 是 Fielding 在其论文的 第五章中定义的一种体系结构样式，它描述了用这种体系结构构建的应用程序的一组约束。REST 被设计成 独立协议，但是同一篇论文的 第六章描述了如何通过 HTTP 应用 REST。

一旦您的 REST 应用程序设计在 HTTP 协议的顶部，您就应该了解 HTTP 语义。HTTP/1.1协议的语义目前在 RFC 7231中进行了描述。

成功的 DELETE请求的响应有效载荷可以:

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

下面的响应状态代码适用于成功的 DELETE请求:

  • 202 : 请求已被接受处理，但处理尚未完成。
  • 204 : 服务器已经成功地完成了请求，并且没有额外的内容要发送到响应负载体中。
  • 200 : 请求已经成功，请求有效负载包含动作状态的表示。

请参阅 RFC 7231的以下引文:

如果一个 DELETE方法被成功应用，原始服务器应该 发送一个 202(接受)状态代码，如果行动可能会成功 (无内容)状态码 已采取行动，不会提供进一步资料, 或 200(OK)状态代码，如果操作已经制定，并且 响应消息包括描述状态的表示形式。


提交答案