RESTful API：刪除實體 - 我應該返回什么結果？

Question

我正在實現一個RESTful API，一個控制器的端點是Delete。 Delete根據要刪除的實體執行兩個操作：它更新實體或從數據庫中刪除實體。 如果刪除更新實體，我將發送HttpStatus 200和更新的實體。 但如果刪除從數據庫中刪除實體，我將只發送HttpStatus 200 。 在一個案例中，我正在返回一個對象。 但在另一種情況下，該對象不再存在。 這是一個好方法還是我錯過了什么？

Answer 1

通常考慮的DELETE HTTP狀態包括：

• 200 OK（MDN）
• 202接受（MDN）
• 204無內容（MDN）

如果您的服務沒有返回任何其他信息， 204是理想的選擇。 它也適用於PUT更新請求。 許多服務返回204包括Docker，如下所示：

• 參考： https ： //docs.docker.com/engine/api/v1.24/

但是，如果您正在實施HATEOAS，最好使用200 OK並為該服務提供一些鏈接。 想想剛剛發布刪除並需要將用戶導航到某個位置的應用程序。 如果不提供該位置的URL，則客戶端應用程序需要保持狀態。 提供帶有鏈接的200 OK允許REST API為客戶端保持狀態。

以下文章很好地描述了這個問題（閱讀博客以獲得更多討論）：

如果您正在構建HATEOAS應用程序，請避免204個響應。

這是我在構建非平凡REST API時學到的REST API設計課程。 為了盡可能支持客戶端，REST API不應返回204（無內容）響應。

從服務的角度來看，204（無內容）響應可能是對POST，PUT或DELETE請求的完全有效的響應。 特別是，對於DELETE請求似乎非常合適，因為您還能說什么呢？

但是，從適當的HATEOAS感知客戶端的角度來看，204響應是有問題的，因為沒有要遵循的鏈接。 當超媒體充當應用程序狀態的引擎時，當沒有鏈接時，就沒有狀態。 換句話說，204響應拋棄所有應用程序狀態。

如果客戶端遇到204響應，它可以放棄，轉到API的入口點，或者返回到它訪問的先前資源。 這兩種選擇都不是特別好。

• 參考： http ： //blog.ploeh.dk/2013/04/30/rest-lesson-learned-avoid-204-responses/

Answer 2

簡短的回答

對於合適的狀態碼DELETE已成功請求是200 ， 202和204 。

答案很長

DELETE根據要刪除的實體執行兩個操作：它更新實體或從數據庫中刪除實體。 [...]這是一個好方法還是我錯過了什么？

DELETE方法不適用於執行更新。

請參閱RFC 7231中的以下引用， RFC 7231是定義HTTP / 1.1協議的文檔之一，有關DELETE方法的詳細信息：

4.3.5。 刪除

DELETE方法請求源服務器刪除目標資源與其當前功能之間的關聯。 實際上，此方法類似於UNIX中的rm命令：它表示對源服務器的URI映射執行刪除操作，而不是期望刪除先前關聯的信息。 [...]

如果刪除操作已成功 ，則服務器可以返回以下狀態代碼之一：

• 202 ：表示該請求已被接受進行處理，但處理尚未完成。
• 204 ：表示服務器已成功完成請求，並且在響應有效負載主體中沒有要發送的附加內容。
• 200 ：表示請求已成功，請求有效負載包括動作狀態的表示。

請參閱同一文檔中的以下引用：

如果成功應用了DELETE方法，則原始服務器應該發送202 （已接受）狀態代碼（如果操作可能成功但尚未頒布），如果操作已經頒布則為204 （無內容）狀態代碼，不再進一步如果已經執行了操作，則提供信息或200 （OK）狀態代碼，並且響應消息包括描述狀態的表示。