在通過 RESTful API 更新資料庫中的物件屬性時，什么被認為是最佳實踐？
例如，給定一個User具有firstName,lastName和age屬性的模型，為了更新用戶的年齡，您是否愿意：
PUT一個 /api/users/:id/ 端點，帶有一個帶有firstName,lastName和age密鑰的 json ，（甚至PATCH該端點僅帶有age密鑰）或...POST帶有單個age密鑰的 json 的 /api/users/:id/age/ 端點？
uj5u.com熱心網友回復：
在通過 RESTful API 更新資料庫中的物件屬性時，什么被認為是最佳實踐？
HTTP 請求將描述對“資源”的某種修改；您的請求處理程式對資料庫進行修改這一事實是隱藏在資源外觀背后的實作細節。
用于更改資訊的資源識別符號應與用于讀取資訊的資源識別符號相同。這里的動機是快取和快取失效——通過使用相同的 URI 進行讀取和寫入，我們可以讓通用組件正確管理它們的快取。
因此，如果您希望客戶端通過 讀取資料庫中的值/api/users/12345，那么您還應該鼓勵客戶端通過 寫入值/api/users/12345。
HTTP 方法描述請求的語意。REST 中“統一介面”約束的部分要點是所有資源都以相同的方式理解請求。
因此，選擇 PUT 還是 POST 取決于您如何在請求正文中傳達您想要的編輯。
在網路上，HTML 瀏覽器無處不在（與 HTML _editors 相反），我們總是使用 HTML 表單為客戶提供他們創建編輯請求所需的資訊。 可以使用 POST。
但是，如果您的客戶端是檔案編輯器，那么另一種選擇是使用遠程創作語意，并讓客戶端將其檔案版本的副本作為請求正文發送。這就是 PUT 合適的情況，當我們試圖告訴服務器“讓你的副本看起來像我的”時。
（當資源非常大時，您可能只想發送更改；那時我們將在請求正文中使用 PATCH 和補丁檔案。）
年齡應該有自己的資源嗎？它應該是描述名字和姓氏的同一資源的一部分嗎？兩個都？
“這取決于”。
如果客戶端快取具有相同資訊的兩個不同資源的回應，那么就會出現快取回應彼此不同步的視窗。對于會導致代價高昂的問題的資訊，您需要確保該資訊只出現在一個地方。
由于兩條資訊一起發生變化，因此將它們視為同一資源的一部分是非常有意義的。對于因不同原因而變化的資訊，您再次需要查看如果資訊在快取中的時間過長，成本有多大，如果我們經常使快取的回應無效，我們是否可以選擇一種所有的快取策略都可以接受的快取策略？資訊？
對于像用戶組態檔這樣的東西 - 年齡每年更改一次，名稱的更改頻率通常比這更低，因此如果您將其全部放入具有單一快取策略的單個檔案中，它可能會正常作業。
將易失的時間敏感資訊與下載成本高的資訊混合在一起，會使最佳快取變得具有挑戰性——如果可以，請避免這種組合。
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/368790.html
標籤：休息
上一篇：其余引數輸入