在我们的项目中，可以通过 REST 检索所有书籍的列表：
GET http://server/api/books/
可以按以下方式检索特定书籍：
GET http://server/api/books/:id/
删除特定书籍很容易：
DELETE http://server/api/books/:id/
现在，对于我的问题：以下调用的结果应该是什么：
DELETE http://server/api/books/
显然，所有的书都被删除了。但是资源书/也应该被删除吗？也就是说，在请求之后：
根据规范，具体的 URI 将在之后消失，我会选择第二个选项。然而，在我看来，这使事情变得复杂和不合逻辑。有一个空的书单比没有书更有意义。
你怎么看？
如果它让您感觉更好，请假设服务器具有在删除图书资源后自动重新创建图书资源的逻辑。:-)
我会选择 200 OK 和一个空列表。如果您真的不喜欢那样，请创建一个名为的新资源 /books/all
做
DELETE /Books/all
然而，这使事情变得复杂和不合逻辑
如何？您正在请求删除资源。该资源被删除。结果是它不再存在了。
如果有的话，在您删除它之后它仍然存在会令人困惑。
我认为允许DELETE /books太冒险了。设计良好的 api 的一部分是避免来自 api 客户端的“简单”错误。很容易发生在客户端代码中出现问题，意外地丢失了 id（例如空字符串变量）并且DELETE /books发送了意外。
我要做的是强制客户进行迭代DELETE /books/{id}，以防他想删除所有书籍。
也许您可以为您的用例提供更多输入：我想知道用例被DELETE /books称为根源的可能性有多大（删除根资源是非常激进的）。也许您正在提供删除子资源，例如/user/{id}/shopping-cart/{id}/books. 如果它是一个更“临时”的资源（如购物车），删除所有书籍的 api 会更有意义。
关于您的另一个问题：因为/books我会返回200并清空列表。在收集情况下，我更喜欢空列表而不是“空”值。