RESTful API：删除实体 - 我应该返回啥结果？

Posted 2023-03-31

【中文标题】RESTful API：删除实体 - 我应该返回啥结果？

【英文标题】：RESTful API: Delete Entity - What should I return as result?RESTful API：删除实体 - 我应该返回什么结果？

【发布时间】：2018-06-11 07:32:10

【问题描述】：

我正在实现一个 RESTful API，一个控制器的端点是删除。 Delete 根据要删除的实体执行两个操作：更新实体或从数据库中删除实体。如果删除更新了实体，我将发送HttpStatus 200 和更新的实体。但如果删除从数据库中删除实体，我将只发送HttpStatus 200。在一种情况下，我正在返回一个对象。但在另一种情况下，该对象不再存在。这是一个好方法还是我错过了什么？

【问题讨论】：

它是DELETE Response on ***的副本

【参考方案1】：

简答

成功的DELETE 请求的合适状态代码是200、202 和204。

长答案

DELETE 根据要删除的实体执行两个操作：更新实体或从数据库中删除实体。 [...] 这是一个好方法还是我遗漏了什么？

DELETE 方法不适用于执行更新。

有关DELETE 方法的详细信息，请参阅RFC 7231（定义HTTP/1.1 协议的文档之一）的以下引用：

4.3.5. DELETE

DELETE 方法请求源服务器删除 目标资源与其当前资源之间的关联 功能。实际上，此方法类似于rm 命令 在 UNIX 中：它表示对 URI 映射的删除操作 源服务器，而不是期望以前 相关信息被删除。 [...]

如果删除操作成功，服务器可以返回以下状态码之一：

202：表示已接受请求进行处理，但尚未完成处理。 204：表示服务器有 成功完成了请求并且没有额外的 要在响应负载正文中发送的内容。 200：表示请求已成功，请求负载包含操作状态的表示。

请参阅同一文档中的以下引用：

如果DELETE 方法成功应用，源服务器应该 如果操作可能成功，请发送202（已接受）状态代码 但尚未制定，204（无内容）状态代码如果 已采取行动，无需提供进一步的信息， 或 200 (OK) 状态码（如果已执行该操作并且 响应消息包括描述状态的表示。

【参考方案2】：

DELETE 通常考虑的 HTTP 状态包括：

200 OK (MDN) 202 Accepted (MDN) 204 No Content (MDN)

204 是您的服务不返回任何附加信息的理想选择。 PUT 更新请求也很受欢迎。许多服务返回204，包括如下所示的Docker：

参考：https://docs.docker.com/engine/api/v1.24/

但是，如果您正在实施 HATEOAS，最好使用200 OK 并为该服务提供一些链接。考虑一个刚刚发出删除命令并需要将用户导航到某个位置的应用程序。如果不提供该位置的 URL，客户端应用程序需要保持状态。提供带有链接的 200 OK 允许 REST API 为客户端保留状态。

以下文章很好地描述了这个问题（阅读博客了解更多讨论）：

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

这是我在构建重要的 REST API 时学到的关于 REST API 设计的课程。为了尽可能支持客户端，REST API 不应返回 204（无内容）响应。

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

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

如果客户端遇到 204 响应，它可以放弃，转到 API 的入口点，或者返回它访问的上一个资源。这两个选项都不是特别好。

参考：http://blog.ploeh.dk/2013/04/30/rest-lesson-learned-avoid-204-responses/

【讨论】：

根据RFC 7231，服务器可以返回200、204和202。详情请见我的answer。