REST：DELETE和業務邏輯條件

Question

當在REST API中實施業務邏輯並使用什麼HTTP狀態代碼時，事實上/常規的做法是什麼？

例如，可以說我有一個玩家實體和一個團隊實體。一支球隊可以有任意數量的球員。

假設我的業務邏輯（當前）阻止團隊被刪除，直到所有玩家已被明確從團隊中刪除。

如果執行

DELETE http://api.foo.com/teams/15

，它仍然具有與之關聯的玩家，你會返回一個HTTP 409（衝突）或HTTP 412（預處理失敗）？ 412似乎更合乎邏輯，因爲我更喜歡使用409來表示樂觀鎖定條件。

或者 - 甚至應該在REST API中強制執行業務邏輯條件嗎？也就是說，如果有人執行

DELETE http://api.foo.com/teams/15

不應該只是刪除所有玩家，然後自動刪除該團隊？允許DELETE執行的更傳統，因爲REST API可以被視爲比UI界面更「低級」或更「原始」的？

最後，關於查詢參數在資源URI什麼：

DELETE http://api.foo.com/teams/15?force=true

這表明，「是的，我知道這不會與球員仍在隊中是允許的，但做無論如何「。

這裏的想法是，刪除一個團隊可能是一個重量級的操作，會帶來顯着的影響，並且只有在最終用戶真的確定他們想要時纔會這樣做。

換句話說，你做了多少手工操作（用'你確定嗎？'錯誤代碼）還是你沒有任何檢查就執行它？我不太確定這是否應該只在用戶界面或REST API或兩者中執行。大多數人今天如何解決這個問題？

Answer 1

客戶試圖做某些業務原因不是一個有效的請求。因此，我將使用400.如果要傳達其他詳細信息，請使用ReasonPhrase/entity body。

Answer 2

412在這種情況下將不正確，因爲這是基於對請求頭字段的評估（請參閱this question何時使用HTTP 412）。這裏的正確狀態代碼是403 Forbidden - 即請求理解，但拒絕這樣做，授權不會有幫助。您可以在響應主體中向客戶提供更多詳細信息。

至於是否應該實施業務邏輯，這完全取決於您。您甚至可以選擇基於ACL實施這種檢查 - 例如，一旦所有玩家都被刪除，某些用戶只能刪除團隊，而管理員可以不管是否刪除團隊。非管理員用戶爲玩家團隊發出DELETE請求應該返回401 Unauthorized（即拒絕這些憑據的操作）。管理員用戶將得到一個200.

編輯：更多信息，一如既往，在RFC 2616。

Answer 3

我曾在REST服務託管的lotus notes上工作過，如果我們需要刪除lotus notes中的任何條目，我們要求設置'confirm/force'true參數，以確保調用者（UI/REST Client ）知道刪除。如果你的服務是REST服務，我認爲在UI級別上還不夠，我們還需要在REST URL中有相同的約束。

我還沒有遇到像你提到的任何情況（刪除團隊應該刪除播放器），但我會更傾向於在這種特殊情況下的412代碼。