在寧靜的服務中處理孤立數據

Question

假設我有一個具有任務列表的RESTful服務。

GET mycorp/api/v1/tasks 

這些任務中的每一個都可以有一個或多個上下文。

GET mycorp/api/v1/tasks?context=somecontext 

在使用過程中，用戶會刪除一批任務。

DELETE mycorp/api/v1/tasks?context=somecontext 

讓我們假設一旦執行此操作，我們已經是現在孤立的系統，因爲上面的DELETE操作的一些背景。讓我們假設可以讓孤立的上下文來保存用戶不得不一遍一遍地輸入相同的上下文。

如果用戶DID想要顯式刪除這些上下文，那麼在REST上下文中正確的方法是什麼？我自然傾向於兩種選擇。

DELETE mycorp/api/v1/tasks?context=somecontext&&deleteorphancontexts=true 

而且還

DELETE mycorp/api/v1/contexts?isorphaned=true 

我還是新來休息，什麼以確保我打造的API是剛性的無意義。

Answer 1

首先，REST並不是一套嚴格的指導方針，所以對此沒有明確的答案，但我認爲它會幫助你將不同的URL視爲資源（畢竟REST是關於什麼的）。

向服務器發送DELETE請求時，指示它刪除該位置的資源。在你的例子中，你假定你正在刪除一個集合的內容，但你實際上是在指示服務器刪除集合本身。因此，如果您在之後立即發出GET請求，則應該會得到204（無內容）響應，而不是200個帶有空集合的響應。如果那是合適的，那麼你的問題就解決了。

在我看來，對單個上下文/任務使用DELETE請求會更好，因爲它與PUT請求相反。通過發出包含刪除指定內容的命令的POST請求來修改集合更爲正確。

這樣，您可以張貼到

MyCorp的/ API/V1 /上下文

併發送指示服務器刪除所有孤兒的命令。

我更喜歡這個的原因是，您將上下文路徑當作一個集合來處理，其中某些項目可能會成爲孤兒。

通常，當你有疑問POST是你的朋友，因爲它是HTTP的小丑。