REST-httpdelete-semantics-only删除子体

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

GET http://server/api/books/

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

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

删除特定书籍很容易：

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

现在，我的问题是：以下电话的结果应该是什么：

DELETE http://server/api/books/

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

是否应获取/books/return 200，且列表为空？或

应该找不到GET/books/return 404吗

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

你觉得怎么样

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

怎么做？您正在请求删除资源。该资源已被删除。结果是它不再存在了

---

如果有什么问题的话，在您删除它之后，它仍然存在是令人困惑的。

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

我要200美元，好的，还有一张空名单。如果您确实不喜欢，那么创建一个名为

/books/all

做

DELETE /Books/all

---

我认为允许

删除/book

太冒险了。设计良好的api的一部分是避免api客户端的“容易”错误。在客户端代码中很容易出现问题，id（例如空字符串变量）意外丢失，并且发送了意外的

DELETE/books

我要做的是强制客户机遍历

DELETE/books/{id}

，以防他想要删除所有书籍

也许您可以在您的用例上提供更多的输入：我想知道该用例有多大可能是根源代码所称的

DELETE/books

（删除根资源是非常激进的）。可能您正在提供删除子资源的功能，例如

/user/{id}/shopping cart/{id}/books

。如果它是一种更“暂时”的资源（如购物车），那么删除所有书籍的api将更有意义

---

关于你的另一个问题：对于

/books

，我将返回

200

和空列表。在收藏案例中，我更喜欢空列表而不是空值。

按照您的逻辑，有一个问题：假设只剩下一本id为50的书。现在，调用DELETE/books/50/。你应该买什么/书/还什么？200行还是404行？我同意。然而，这就是我的观点，这意味着/books/可以返回404（如果调用了DELETE/books/或200）（如果调用了DELETE/books/id of last book/）。这意味着在后端，我们必须记住这一点。这使它变得不必要的复杂。你不同意吗？介绍/书籍/一切都有意义。我将其命名为/books/@all（如果这是一个有效的URI，我不知道它的开头），以明确这不是一本真正的书。在这个解决方案中，将返回什么GET/books/all？没有内容？还有什么？@Appelsein您可以不返回任何内容，您可以返回405-不允许使用的方法，或者您可以重定向到

/books

@Appelsein@是保留字符，可能使用下划线或~@appelseen REST都是关于链接的。您位于/books的资源应提供链接，以允许您的客户与您的/books资源交互（创建新书只是您可能希望提供的链接的一个示例）。如果您删除了/books，然后开始返回404，您的客户将如何添加新书？因此，您需要不断返回一个空列表，其中包含添加新书的链接。对不起，我对/books的描述不太准确。在我们的项目中，它确实是一个暂时的收集资源，就像您给出的购物车示例一样。从这个意义上讲，删除整个集合是有意义的。也就是说，返回200 OK并用一个空集合（而不是404）回答似乎是共识，尽管这在HTTP DELETE语义方面有点不符合逻辑。是的，我也认为如果这是一个暂时+常见的事情，那么删除..../书籍是完全好的。当考虑收藏资源DELETE+200时，我认为用以下短语是合乎逻辑的：“你正在从书架上移除所有书籍，但书架仍然在那里”，我从语义角度同意。然而，HTTP DELETE的细节说明URI后面的资源应该消失。如果你接受你的（非常合乎逻辑的）假设，情况就不是这样了。这就是我的问题。这就是说，务实的方法在这里可能是最好的。