用於軟刪除和恢復軟刪除資源的REST是有限的

Question

這不是一個技術性問題，而是更多關於該主題的反思。

REST已經演示了一種使用HTTP協議來服務資源的好方法，並讓開發人員通過分割資源和用戶界面來實現最乾淨的項目（現在後端只使用REST API來處理後端）。

關於這些API，大部分時間我們都使用GET，PUT/PATCH（嗯？），POST和DELETE，都是模仿CRUD數據庫。

但隨着時間花在我們的項目上，我們覺得UX可以通過添加大量的強大功能而得到改進。例如，爲什麼用戶覺得害怕刪除資源？爲什麼不只是建立一個恢復系統（就像我們在Google Keep應用程序中看到的那樣，可以讓我們撤消在UX中我認爲非常棒的刪除）。

防止無意刪除的做法之一是使用表中表示資源的列。例如，我即將刪除一本書，因此通過單擊刪除按鈕，我將只在數據庫中將此行標記爲「已刪除= TRUE」，並防止顯示在瀏覽資源列表（GET）時刪除的行。 。

由於DELETE和DESTROY「方法」之間沒有區別，這最後與我們親愛的REST模式衝突。

我的意思是，我們應該考慮讓REST發展到我們的用戶體驗需求，所以我的意思是讓HTTP協議不斷髮展，或者應該保持純粹的資源管理，我們應該遵循HTTP協議而不嘗試打擾它，只是適應它使用解決方法（如使用PATCH軟刪除）？

Personnaly我希望看到至少4個新的協議，因爲我們正試圖資格的資源儘可能的好：

• DELETE成爲防止他人的方法來對其產生影響的方式
• DESTROY成爲該資源
• RECOVER是一種方式說，以其他方法「嗨，他是回來，留完全消除痕跡更劇烈調整」
• TRASH是得到這樣的，但只有被刪除的資源

是什麼讓我想想我是一個乾淨的REST的解決方案來處理這個資源行爲的研究。我已經看到了一些網站上張貼包括

• https://www.pandastrike.com/posts/20161004-soft-deletes-http-api
• https://philsturgeon.uk/rest/2014/05/25/restful-deletions-restorations-and-revisions/
• ...

該建議我們使用PUT或PATCH，使軟刪除的東西可用，但我有種感覺它聽起來不對，不是嗎？

我對這個問題的看法：

• 有沒有提出新的HTTP方法和更新先前的方法之間的一大步（聽說HTTP/2是一個東西，也許我們可以把那些嗎？）
• 在網絡開發領域之外它有意義嗎？我的意思是，這種改變可能會影響我們的其他領域嗎？

Answer 1

即使在web開發領域，我也不確定這是否合理;起始前提似乎是錯誤的。

RFC 7231提供了這樣的解釋，根據資源本身的特定語義目標資源的過程中表示封閉在請求POST

POST方法請求。

謎語：如果這是POST的官方定義，爲什麼我們需要GET？目標可以用GET做的任何事情都可以通過POST完成。

答案是GET的附加約束條件允許參與者僅使用消息中包含的信息作出智能決策。

例如，由於標題數據通知中間組件，該方法是GET，因此中間設備知道接收到消息時的動作爲safe，因此如果響應丟失，則可以重複該消息。

抓取網頁的整個概念取決於您可以遵循任何安全鏈接來發現新資源的事實。

瀏覽器可以預取表示，因爲編碼在鏈接中的信息告訴它該消息是安全的。

Jim Webber描述它的方式：「HTTP是一個應用程序，但它不是你的應用程序」。 HTTP規範的作用是定義消息的語義，以便通用服務器可以理解通用客戶端。

使用你的例子; API消費者可能會關心刪除和銷燬之間的區別，但瀏覽器不會;瀏覽器只是想知道要發送什麼消息，重試規則是什麼，緩存規則是什麼，如何針對各種錯誤條件等等。

這就是REST的力量 - 您可以使用任何理解媒體類型的表示，並獲得正確的行爲，即使瀏覽器完全不瞭解應用程序語義。

瀏覽器不知道它正在與互聯網留言板或路由器的控制面板通話。

總之：您的想法在我看來，好像您試圖通過更改消息語義來實現更豐富的應用程序語義;這違反了關注點的分離。