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

Question

我们说我有一个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有严格的定义。这些问题只能通过松散的意见来回答。

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（无内容）？毕竟，资源刚被删除。

     

资源通常是集合的成员，或者以其他方式拥有＆＃39;通过一个容器。例如，http://foo.ploeh.dk/api/tags/rock表示＆＃34;摇滚＆＃34;标签，但另一种看待它的方式是/ rock资源包含在标签容器中（它本身就是一个资源）。这应该是Atom Pub用户所熟悉的。

     

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

     

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

Answer 3

  

DELETE的响应正文应包含哪些 RESTful约定？

REST是Fielding在他的论文的chapter 5中定义的一种架构风格，它描述了使用这种架构构建的应用程序的一组约束。 REST被设计为协议无关，但同一论文的chapter 6描述了如何通过HTTP应用REST。

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

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

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

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

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

请参阅RFC 7231：

中的以下引用

  

如果成功应用DELETE方法，原始服务器应该应该   如果操作可能成功，则发送202（已接受）状态代码   但尚未颁布，如果是204（无内容）状态代码   行动已经颁布，不再提供进一步的信息，   或者200（OK）状态代码（如果已执行该操作）   响应消息包括描述状态的表示。

Answer 4

我认为最好的方法是不管电话如何都保持一致。自从我使用许多API以来，从一个更务实的角度说这个。我真的不喜欢每个响应处理不同的标题，状态代码等。 200响应是最好的，身体实际上可以对响应有所了解。例如DELETE请求确实删除了任何东西并不明显。响应可能表明该错误或是否存在错误。