我應該期待HTTP DELETE在哪個URI？

Question

這更多的是一個概念完整性問題，一直困擾着我。

HTTP的DELETE方法應該是冪等的，而REST的URI應該實際上代表事物。但它似乎只在反向方向中定義：每個資源必須有一個URI，但給定的URI似乎不需要資源。我猜，URI可以定義爲指向空/空資源。

這似乎確實相關的唯一時間是在DELETE請求中。最好的地方放在哪裏？ example.com/users/標識要刪除的資源的內容，還是example.com/users/USERNAME更好？

DELETE中的內容在HTTP和REST中看起來很好。 （概念：根據其他SO問題，各種框架會悄悄地從DELETE請求降內容，然後才能對其進行處理）

因此，這裏是我的想法：每一個例子似乎使用後者的方案 - 在那裏你刪除資源其 URI，但不從其父集合中刪除資源 URI - 但在成功刪除後資源應該停止存在。在這種情況下，URI應該大聲失敗，恕我直言。但是這會否定DELETE的冪等性，導致我認爲DELETE應該對集合進行操作，其內容指定要刪除的實際資源。

很顯然，每個人都會做我不喜歡的事情，我可能會爲了我的用戶的理智去遵守它，但是在哪裏有明確說明的地方，或者我缺少什麼明顯的東西那讓我錯了？

Answer 1

根據HTTP標準「DELETE方法請求源服務器刪除由Request-URI標識的資源。」 - 沒有任何關於任何類型的請求主體。

在這種情況下，URI應該大聲地失敗，恕我直言。但是這會否定DELETE的冪等性

只返回一個404。冪等性的要點是，提交相同的DELETE請求兩次不會導致服務器狀態與提交一次結果不同。失敗不會導致此問題（除非服務器關閉或某事）

Answer 2

A DELETE請求應該只適用於您想要刪除的資源的URI。對於通過集合刪除的東西，POST或PUT對該集合更合適。

您可以通過檢查資源並刪除它（如果它存在並返回2xx）來實現對DELETE請求的響應，否則返回2xx（例如，如果發送了重複請求）。讓這種方法冪等性的一點是，它不會「失敗」 - 它根本不被認爲是失敗的。就像PUT不區分「創建」和「更新」一樣。