首頁猿問補丁與合并補丁哪個合適？

補丁與合并補丁哪個合適？

Java

肥皂起泡泡 2022-11-10 16:43:19

嘗試查看哪些模型最適合api（低更新，但對象結構可能經常更改，高讀取應用程序）我有這樣的資源史詩（id、名稱、描述、開始日期、結束日期、狀態、故事）故事（id、名稱、描述、開始日期、結束日期、狀態、任務）任務（id、名稱、描述、開始日期、解決日期、解決方案）如果我只需要支持這些更新，更新史詩名稱或描述或日期或狀態更新故事名稱或描述或日期或狀態更新任務名稱或描述或日期或狀態這有道理嗎？PATCH和application/merge-patch+json RFC 7396資源應該匹配目標對象結構史詩/{id}史詩/{id1}/stories/{id2} .. 等等PATCHwithapplication/json -我傾向于選擇這個，因為沒有必要如此嚴格地執行RFC 7396和靈活地更新更新規則。您要更新的自定義規則（但從技術上講 - 我可以只發送需要更新的資源屬性，類似于application/merge-patch+json）史詩/{id}史詩/{id1}/stories/{id2} .. 等等PUT和application/json資源應匹配所有字段并創建新對象并替換（或作弊并僅像補丁一樣更新）史詩/{id}史詩/{id1}/stories/{id2} .. 等等PUT和application/json或作弊，只更新補丁，但使用 put史詩/{id}史詩/{id1}/stories/{id2} .. 等等

查看完整描述

1 回答

慕容3067478

TA貢獻1773條經驗獲得超3個贊

從 REST 的角度來看，要記住的重要一點是統一的接口——你有一些具有application/json表示的資源。我可以GET代表您，并使用我最喜歡的任何工具對其進行本地編輯。

如果我想提議更改資源以匹配我的表示，我們從 HTTP 協議中選擇適當的方法。換句話說，HTTP 中的方法都是“通過網絡傳輸此文檔”域的一部分。（參考：吉姆·韋伯，2011 年）。

因此，實際上，支持“所有這些”是確保可以使用最廣泛的通用客戶端與您的資源交互的方法。

PUT /31E772D3-0157-4B52-8243-75EEAB946E65

Content-Type: application/json

完全合理的起點；它有幾個優點 - 語義是冪等的，因此客戶端知道丟失的請求可以重復，并且 HTTP PUT包含重要用例的語義，例如我們接受您的表示，這樣可以減少網絡壓力。

當表示遠大于更改時，PUT 可能是一個不幸的選擇。