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

Question

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

Answer 1

简短回答

成功请求的合适状态代码是、和。DELETE200202204

长答案

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

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

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

4.3.5. 删除

该DELETE方法请求源服务器删除目标资源与其当前功能之间的关联。实际上，这种方法类似于rmUNIX中的命令：它表达的是对源服务器的URI映射的删除操作，而不是期望删除先前关联的信息。[...]

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

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

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

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

Answer 2

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

• 200 好（MDN）
• 202 已接受（MDN）
• 204 无内容（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/