在REST中，我是否應該返回表示以響應PUT？

可以想象，另一個客戶也在此期間修改了資源的其他方面。那麼，儘管帶寬開銷，最好的做法是始終在對PUT的響應中包含完整的表示形式？在REST中，我是否應該返回表示以響應PUT？

來源

2010-01-14 Kevin Pauli

返回與交易相關的唯一標識符會更好嗎？節省帶寬，避免可能不得不返回到服務器，以確保在此期間沒有發生任何事情。即如果你返回的數據，它可能無論如何是陳舊的。 – jldupont 2010-01-14 16:29:35

這很奇怪......我在20分鐘前問自己那個同樣的問題...... – skaffman 2010-01-14 16:31:07

Jldupont的評論指出了我的正確方向。我將使用ETags通過使用If-match頭文件as described here執行條件PUT來確定資源是否已被修改。

然後，如果發生衝突，我將讓用戶決定是從服務器（GET）獲取最新表示還是用自己的覆蓋更改。

因此，沒有必要將響應中的完整表示返回給PUT，只是爲了幫助衝突檢測和解決。

來源

2010-01-14 16:44:31

我喜歡將GET和DELETE看作一對 - 它們只取一個ID。

POST和PUT看起來也是一對。他們採取序列化的對象，並使其持久。因此，我認爲POST和PUT都應該返回創建的結果對象。

在某些情況下，您可能會將額外計算作爲持久性的一部分，並且PUT可能會反映這些計算結果。從技術上講，這可能是第三種正常形式違規，因爲你有派生值。但通常，Web服務的全部要點是在POST和可能的PUT中進行一些增值計算。

來源

2010-01-14 16:36:14

我很欣賞你的理念，但不同意（至少部分）。 HTTP規範沒有（就像GET一樣）要求/禁止/限制DELETE只是一個URL。更重要的是，你不是唯一認爲這種情況的人（更重要的是，像Talend這樣的主要軟件項目是圍繞這個假設設計的。）DELETE對單個實體的請求不需要一個主體（如GET），但DELETE對集合的請求是非常激烈的，沒有一些數據可以改善請求 – Anthony 2015-09-11 11:51:48

在許多情況下（即使不是大多數情況下），即使服務器通過PUT創建或更新，服務器也會向資源添加內容。示例是時間戳，版本號或從其他人計算出的任何元素。即使您遵循RESTful方法並且不使用PUT進行部分更新，情況也是如此。

僅憑這個原因，返回更新或創建的資源表示通常是PUT請求的一個好主意。但是，我不一定稱之爲「最佳實踐」 - 如果您放置一個巨大的2GB圖像文件，則可能不希望將其作爲響應的一部分返回。另一方面，包括ETag在內，絕對值得「最佳實踐」地位。

來源

2010-01-14 18:28:25

您可能希望考慮返回一個303 See Other響應，將Location標頭設置爲已更新資源的URI（Post/Redirect/Get）。這樣客戶端即使在臨時編輯過程中也收到資源的當前狀態（如果它選擇遵循Location標題），並且在使用瀏覽器時不存在重新提交請求的危險。

但是，此模式排除發送對客戶端可能有用的適當的成功代碼（200 OK,202 Accepted等）。另外，根據你對REST的定義，你可能會認爲這是非標準的做法。

如果客戶端可能是由人們操作的瀏覽器，這可能更合適。

來源

2010-11-02 17:42:38

在REST中，我是否應該返回表示以響應PUT？

回答

相關問題