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和空列表。 在收集情況下，我更喜歡空列表而不是“空”值。