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/

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

1. 应该使用空列表获取/预订/返回200 OK吗？或
2. 应该找不到GET / books / return 404吗？

根据规格说明具体的URI将会消失，我会选择第二种选择。然而，在我看来，这使得事情变得复杂和不合逻辑。拥有空书籍列表更有意义，而不是没有书籍。

您怎么看？

Answer 1

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

我会去200 OK和一个空列表。如果你真的不喜欢它，那么创建一个名为/books/all

的新资源

并做

DELETE /Books/all

Answer 2

  

但是，这会让事情变得复杂和不合逻辑

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

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

Answer 3

我认为允许DELETE /books风险太大。精心设计的api的一部分是避免api-client端的“轻松”错误。很容易发生在客户端代码出错的情况下，意外地丢失了id（例如空字符串变量）并且发送了无意的DELETE /books。

我要做的是强制客户端迭代DELETE /books/{id}，以防他想要删除所有图书。

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

关于您的其他问题：对于/books，我会返回200并清空列表。在收集案例中，我更喜欢空列表而不是'null'值。