RESTful API 最佳實踐：用於字段更新的全局與專用端點

Question

在通過 RESTful API 更新數據庫中的 object 屬性時，最佳實踐是什么？

例如，給定具有firstName 、 lastName和age屬性的User model ，為了更新用戶的年齡，您願意：

• 使用帶有firstName 、 lastName和age鍵的PUT放置 /api/users/:id/ 端點，（甚至只使用age鍵PATCH該端點）或...
• 使用POST和單個age密鑰發布 /api/users/:id/age/ 端點？

Answer 1

在通過 RESTful API 更新數據庫中的 object 屬性時，最佳實踐是什么？

HTTP 請求將描述對“資源”的某種修改； 您的請求處理程序對數據庫進行修改的事實是隱藏在資源外觀后面的實現細節。

用於更改信息的資源的標識符應與用於讀取信息的資源的標識符相同。 這里的動機是緩存和緩存失效——通過使用相同的 URI 進行讀取和寫入，我們使通用組件能夠正確管理它們的緩存。

因此，如果您希望客戶端通過/api/users/12345從數據庫中讀取值，那么您還應該鼓勵客戶端通過/api/users/12345寫入值。

---

HTTP 方法描述了請求的語義。 REST 中“統一接口”約束的部分要點是所有資源都以相同的方式理解請求。

因此，PUT 與 POST 的選擇取決於您如何在請求正文中傳達您想要的編輯。

On the web, where HTML browsers were ubiquitous (as opposed to HTML _editors), we always used HTML forms to provide clients with the information they needed to create their edit requests. 可以使用 POST 。

但是，如果您的客戶端是文檔編輯器，那么另一種選擇是使用遠程創作語義，並讓客戶端將其文檔版本的副本作為請求正文發送。 當我們試圖告訴服務器“讓你的副本看起來像我的”時，這就是 PUT 合適的情況。

（當資源非常大時，您可能只想發送更改；那時我們將在請求正文中使用帶有補丁文檔的 PATCH。）

---

年齡應該有自己的資源嗎？ 它應該是描述名字和姓氏的同一資源的一部分嗎？ 兩個都？

“這取決於”。

如果客戶端正在緩存具有相同信息的兩個不同資源的響應，那么將出現 windows，其中緩存的響應彼此不同步。 對於會造成代價高昂問題的信息，您需要確保該信息僅顯示在一個地方。

由於兩條信息一起變化，因此將它們視為同一資源的一部分非常有意義。 對於因不同原因而發生變化的信息，您再次需要查看如果信息在緩存中停留時間過長的成本是多少，如果我們經常使緩存的響應無效，我們是否可以選擇一種對所有人都可接受的緩存策略信息？

對於像用戶配置文件這樣的東西 - 年齡每年更改一次，名稱的更改頻率通常比這更小，因此如果您將其全部放入具有單個緩存策略的單個文檔中，它可能會正常工作。

將易失性的時間敏感信息與下載成本高昂的信息混合起來會使最佳緩存具有挑戰性——如果可以的話，請避免這種組合。