如果DELETE不可能，則為REST HTTP狀態代碼

Question

當資源上無法進行DELETE （但不涉及用戶權限）時，我的問題是關於HTTP狀態代碼的非常通用的問題。

我們在一種資源上有一個RESTful API。

DELETE方法在資源上被授權，但在某些情況下無法刪除資源（如果有數據綁定到此資源）。

在這種情況下，返回客戶端的正確HTTP狀態代碼是什么？

以下是我收集的一些可能性以及為什么它在我的案例中似乎不合適：

• 403 （ 禁止 ）：似乎主要與用戶的權利有關。
• 405 （ 不允許的方法 ）：似乎API不是為這種類型的資源響應此方法而設計的。
• 409 （ 沖突 ）：似乎合適，但客戶應該有可能解決與API的沖突，但這不是這種情況。

更新：無法通過REST API更改阻止資源被刪除的數據綁定。 但是，資源可以通過其他方式“釋放”，因為數據所來自的數據庫也可以被其他應用程序訪問，這些應用程序可能會更改資源的狀態（DB中的SQL DELETE總是可以這樣做）。

Answer 1

我認為409是最合適的，因為它在RFC中的措辭：

409（沖突）狀態代碼表示由於與目標資源的當前狀態沖突而無法完成請求。 此代碼用於用戶可能能夠解決沖突並重新提交請求的情況。 服務器應該生成一個有效載荷，其中包含足夠的信息供用戶識別沖突源。

（強調我的）

根據我對問題描述的理解，不允許DELETE的原因與目標資源的當前狀態完全沖突 。 如RFC中所示，響應有效載荷可以指示原因，並且可選地 ，用戶可能能夠解析它。 我沒有看到規范中的任何內容使409不合適只是因為API不提供沖突解決的可能性。

Answer 2

如果客戶端無法解決沖突並稍后刪除請求，那么409 Conflict響應肯定是錯誤的。 也就是說，除非資源有狀態跟蹤是否可以刪除，否則409 Conflict不適合。

403 Forbidden並不一定意味着沒有授權：

但是，出於與憑證無關的原因，可能會禁止請求。
- RFC 7231

但這意味着通常存在。 您可以使用此代碼，但可能會引起一些混淆。 如果方法實際上也需要授權，那將特別棘手 - 您需要在響應中使用代碼或其他內容來指示失敗是與授權相關還是資源是不可刪除的。

我認為405 Method Not Allowed是正確的方法。

405（方法不允許）狀態代碼表示請求行中接收的方法由源服務器知道但目標資源不支持。
- RFC 7231

此資源不支持DELETE方法。 這聽起來就像你所描述的那樣。 HTTP規范實際上沒有一種資源的概念 - 只是一種資源。 碰巧人們將相同端點下的個人資源分組以獲得理智，但這對開發人員和用戶來說只是一種便利。 就HTTP規范而言， /widgets/12和/widgets/15和/widgets/3453是三種不同的資源。 同一個對象代表服務器上所有這三個資源的事實完全無關緊要。 我認為這是你想到的“類型”，但對於HTTP來說這只是一個實現細節。