REST API應該保護背後的數據嗎？

Question

在DELETE查詢中，如果我的REST API盲目地繼續或警告它並要求確認，可能會級聯移除大量數據？

我正在構建一個API，用於抽象存儲在關係數據庫中的複雜數據的操作。刪除其他項目引用的項目應邏輯上刪除它們，然後級聯。

一個簡單的例子（與真實案例無關）將是一組三個「樹/分支/葉」表：葉子行對分支的ID有一個外鍵，並且分支行同樣包括樹ID。 API可以在任何級別啓用DELETE，但是如果刪除樹項目，它將內部級聯以刪除直接或間接引用它的所有分支和葉子。

等了一樹刪除查詢，該API可以：

• 只是遵守並執行所有級聯清除
• 拒絕，理由是它會破壞完整性，所以你必須刪除所有相關項目先手動（不太實際）
• 不要刪除任何東西併發回語句「這樣會刪除1棵樹，31個分支和987棵樹葉，請確認」。確認可以採取URL（/ force）中額外的頭部或後綴的形式，但這兩者都不是非常REST，並且根據我的經驗，在編寫客戶端時（通常只發送delete + confirm查詢），這些東西通常會被直接繞過。我也猶豫在HTTP代碼上這樣回覆。

我傾向於認爲API應該保持簡單，並且應該在客戶端使用Foolsafe保護，但會欣賞外部智慧。

Answer 1

像往常一樣，這些問題的答案真的是'它取決於'。就個人而言，如果你會去不必「確認」大缺失的路線，我反而：

1. 添加depth或cascading頭。而不是'你真的想要這個嗎？'你知道要求開發人員確保他們想要進行深度刪除。 Depth是標準標題，但出現在WebDAV規範中。 Cascading不會，所以你可以用X-作爲它的前綴，這取決於你是否認爲這是個好主意=）
2. 如果沒有指定該頭部，則迴應409。 WebDAV就是這樣做的，並且在這裏有很多意義。

但是，從我的觀點來看，我認爲我寧願有一個'取消刪除'的選項。