REST API：是否應該使用PUT或DELETE來部分更新資源？

Question

我們有一個網站像多元化，作者和客戶都在這里注冊。 作者發布他們的課程，客戶可以對這些課程進行評分。 表結構如下：

作者表：（保存作者的基本信息：一對一）

authorId | 名稱| 聯系| 電郵| 評分

1 | 薩希爾| 9971343992 | shaf@gmail.com | 3.2

authorRating ：（保存給客戶的作者評級：一對多）

ID | authorId | customerId | 評級|

1 | 1 | 101 | 2.7

2 | 1 | 201 | 3.7

當在authorRating表中插入/更新/刪除某些記錄時，author表中的評級將更新。 有一些復雜的算法可以根據authorRating表記錄最終確定author表中的評分。

為此，我們創建了以下API：

PUT api / author / 1 / rating /：如果authorRating表中有任何更改，我們將重新計算該作者的評分，並觸發此API傳遞新的評分。 這接受評分並在作者表中添加/更新。 如果作者表沒有id = 1，則返回驗證錯誤

刪除api / author / 1 / rating /：刪除作者ID = 1的評分，即將其設置為NULL。 如果作者表沒有id = 1，則會返回驗證錯誤。

這是正確的API設計嗎？ 還是應該只公開PUT API，如果它們在PUT API中將等級發送為null，我們將在author表中將其設置為null？

還是我們應該考慮在這里使用PATCH？

Answer 1

至於您只修改一個結構的字段，我認為PATCH在這里更合適，但應將其發送到父資源：

PATCH api/author/1

Answer 2

對於這些評級操作，我將使用類似以下內容的方法：

• 要為作者1插入新的評分，請使用POST /api/author/1/rating
• 要更新作者1的評分，請使用PATCH /api/author/1/rating 。 您可能希望authorRating表中有更多不想更改的數據（例如作者和客戶ID），但您只更新了某些字段，在這種情況下是等級。
• 如您所解釋的，要刪除作者的1級， DELETE /api/author/1/rating是有意義的。

Answer 3

對RESTful API使用POST方法是一種常見的做法。 您幾乎可以張貼任何消息，並可以通過參數處理該消息。 您可以根據需要發布刪除，更新或其他命令。

Answer 4

HTTP是一種協議，它定義了允許操作資源的方法。 可以這么說。 在操縱這些資源時，由調用的操作之一觸發的任何業務邏輯或多或少只是副作用。 盡管某些事情可以通過多種方式實現，但操作（在語義上）略有不同。

RFC 7231中指定的PUT將當前表示替換為請求中提供的表示，它聲明了有關部分更新的以下內容：

通過以狀態與較大資源的一部分重疊的狀態單獨標識資源為目標 ，或者通過使用專門為部分更新定義的其他方法 （例如， RFC5789中定義的PATCH方法），可以進行部分內容更新。

因此，您可以選擇“重疊”資源並更新另一個資源，這樣的效果還可以更改重疊數據，從而也可以更改實際資源中的數據，或者使用PATCH 。

入門者很容易想到另一資源的某些信息被嵌入到實際資源中，並且在更新另一資源時，實際資源的狀態也將因此而改變。 想一想用戶及其地址，即

根據羅伊·菲爾丁（Roy Fielding）的論文，他在論文中寫道：

REST中信息的關鍵抽象是一種資源。 可以命名的任何信息都可以是資源 ：文檔或圖像，臨時服務（例如“洛杉磯今天的天氣”），其他資源的集合，非虛擬對象（例如人）等。 換句話說，任何可能成為作者超文本引用目標的概念都必須符合資源的定義。 資源是到一組實體的概念性映射，而不是在任何特定時間點對應於該映射的實體 。”

資源應通過自己的唯一標識符來命名和引用。 盡管通常不希望將實體直接映射到資源，因為資源可以並且可能應該包含更多信息，以便客戶端采取進一步的措施。

因此，取決於您是否將評級視為一個好的實體和/或一個好的資源。 盡管這是一個自以為是的立場，但我不是這個的忠實擁護者。

DELETE具有一些特殊的語義。 盡管通過刪除特定資源的關聯（URI）將使資源不可用，但它實際上不能保證刪除文件。 實際上，刪除的資源將取決於實現。

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

...

如果目標資源具有一個或多個當前表示，則它們可能會或可能不會被原始服務器銷毀，並且相關的存儲可能會或可能不會被回收，這完全取決於資源的性質及其由原始服務器的實現（超出了本規范的范圍）。 ...通常，假定原始服務器僅對具有預定機制以完成刪除的資源允許DELETE。

通常， DELETE僅應用於先前通過PUT或POST創建且已通過自己的Location響應標頭確認創建的資源。

話雖如此，您一直在尋求這是否是正確的API設計。 實際上，沒有對與錯，您所采取的立場主要是自以為是。 只要您遵守HTTP協議規范（在您的特定情況下），您就不會違反REST架構師原則。 如果您以一種可唯一識別的方式設計評分資源，則可以使用Delete取消引用作者的相應評分（並可能從數據庫中刪除數據），或將包含該評分資源的新內容的放置請求發送到各自的端點。

不過請記住，服務器應盡最大努力告訴客戶端它可以采取的下一步操作，而不必讓客戶端獲得有關您的API的一些帶外信息，否則，您會將客戶端與API耦合，因此將來更改API時可能會引起問題。