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

Question

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

Answer 1

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

• 200 OK（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/

Answer 2

简短的回答

对于合适的状态码DELETE已成功请求是200 ， 202和204 。

答案很长

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

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

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

4.3.5。 删除

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

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

• 202 ：表示该请求已被接受进行处理，但处理尚未完成。
• 204 ：表示服务器已成功完成请求，并且在响应有效负载主体中没有要发送的附加内容。
• 200 ：表示请求已成功，请求有效负载包括动作状态的表示。

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

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