REST - HTTP DELETE - 语义 - 仅删除后代

Question

在我们的项目中，可以通过 REST 检索到所有书籍的列表：

GET http://server/api/books/

可以按以下方式检索特定书籍：

GET http://server/api/books/:id/

删除特定书籍很容易：

DELETE http://server/api/books/:id/

现在，对于我的问题：以下调用的结果应该是什么：

DELETE http://server/api/books/

显然，所有的书都被删除了。 但是资源书/也应该被删除吗？ 也就是说，在请求之后：

1. GET /books/ 应该返回 200 OK 和一个空列表吗？ 或者
2. GET /books/ 是否应该返回 404 未找到？

根据规范，具体的 URI 将在之后消失，我将 go 作为第二个选项。 然而，在我看来，这使事情变得复杂和不合逻辑。 有一个空的书单比没有书更有意义。

你怎么看？

Answer 1

如果它让您感觉更好，请假设服务器具有在删除图书资源后自动重新创建图书资源的逻辑。 :-)

我会 go 获得 200 OK 和一个空列表。 如果你真的不喜欢这样，那么创建一个名为/books/all的新资源

做

DELETE /Books/all

Answer 2

然而，这使事情变得复杂和不合逻辑

如何？ 您正在请求删除资源。 该资源被删除。 结果是它不再存在了。

如果有的话，在您删除它之后它仍然存在会令人困惑。

Answer 3

我认为允许DELETE /books风险太大。 精心设计的 api 的一部分是避免来自 api 客户端的“简单”错误。 很容易发生在客户端代码中出现问题，意外地丢失了 id（例如空字符串变量）并且发送了意外的DELETE /books 。

我要做的是强制客户遍历DELETE /books/{id}以防他想删除所有书籍。

也许您可以就您的用例提供更多输入：我想知道用例将DELETE /books作为根源调用的可能性有多大（删除根资源是非常激进的）。 也许您提供删除子资源，例如/user/{id}/shopping-cart/{id}/books 。 如果它是一个更“短暂”的资源（如购物车），删除所有书籍的 api 会更有意义。

关于您的其他问题：对于/books ，我将返回200和空列表。 在收集情况下，我更喜欢空列表而不是“空”值。