我知道關于此主題的許多最佳實踐問題已被問到，但我無法準確找到我正在尋找的內容。假設我想要一個端點來加入或離開聊天室。我的想法是有一個像這樣的請求：
PATCH /api/chatroom/{roomId}?action=join|leave
這對我來說似乎很可靠，因為 PATCH 通常用于部分更新資源。在這種情況下，我正在更新聊天室資源，洗掉或添加成員。但是，我不喜歡這個，因為有兩個原因：
- 有一個查詢引數
action感覺有點笨重。API 用戶必須知道 的可能值action，并且必須在服務器端顯式處理無效值。 joinvs 的錯誤處理完全不同leave。如果用戶未被邀請加入聊天室，加入請求將回傳錯誤。另一方面，如果用戶不是聊天室成員，則離開請求將回傳錯誤。這種差異讓我覺得這些應該是單獨的端點。
有兩個這樣的端點會更好嗎？
PATCH /api/chatroom/{roomId}/join 和 PATCH /api/chatroom/{roomId}/leave
這感覺更糟，因為join并且leave不是資源。但是，我也喜歡這將事物分為兩個端點。什么是 RESTful 方式來做到這一點？
uj5u.com熱心網友回復：
這對我來說似乎很可靠，因為 PATCH 通常用于部分更新資源。
是的……但我們通常不會僅僅為了修補它們而投入新資源。
TL;DR：可以使用 POST。當一切都是 HTML 和表單時，這就是我們在網路上所做的。
PATCH 和 PUT 一樣，應該理解為帶有附加約束的 POST 訊息。POST 為通用客戶端提供很少的關于正在發生的事情的背景關系；但PATCH更具體 - 補丁表示我們正在提議對請求目標進行編輯，有效負載是一個“補丁檔案”，描述了對表示的更改。
換句話說，如果我們試圖糾正網頁上的拼寫錯誤，PATCH（就像 PUT）是一種我們會使用的方法。
Webber 2011很好地描述了關鍵思想：PATCH 是通過網路域進行通用檔案傳輸的一部分。有用的業務活動（如加入和離開聊天）是在資源模型中操作檔案的副作用。
例如，您可以想象一個包含聊天中所有參與者串列的檔案 - 如果您自己想加入聊天，您可以通過要求服務器將您的姓名添加到其參與者串列中來表示這一點。
一個直接的設計是讓聊天室本身的參與者串列（？），所以請求可能看起來像：
POST /api/chatroom/12345 HTTP/1.1
Content-Type: application/x-www-form-urlencoded
action=join&user=Bob
如果 /api/chatroom/12345 是具有 JSON 表示的資源，那么我們可以通過修補聊天室資源中的參與者串列來獲得類似的結果
PATCH /api/chatroom/12345 HTTP/1.1
Content-Type: application/json-patch json
[
{ "op": "add", "path": "/participants", "value": "Bob" }
]
最好在正文中包含補丁的資訊，而不是 URL。
URI 標識資源；補丁檔案描述了對由 URI 標識的資源的提議更改。
我應該傾向于在資源本身上使用 PATCH，并傳遞我正在尋找的更改的 JSON 表示？
...如果遠程創作是適合您背景關系的介面型別。
一種思考方式：在遠程創作界面中，通過 PUT 還是通過 PATCH 對資源進行更改可能無關緊要。他們都表達了相同的基本想法（請讓您的副本看起來像我的副本）。
這意味著推斷預期的“業務活動”意味著識別檔案中的更改，然后做正確的事情。將此與 POST 進行對比，后者更適合“我將告訴您我想要什么，您弄清楚檔案應該如何更改”。
uj5u.com熱心網友回復：
PATCH /api/chatroom/{roomId}/join and PATCH /api/chatroom/{roomId}/leave
由于單一責任，我也這樣稱呼。
資源并不總是需要的，操作一些東西也是可以的。
/api/cart/empty-all
/api/cart/remove-all
...
轉載請註明出處，本文鏈接：https://www.uj5u.com/yidong/328440.html
上一篇：使用HTTPV1安排FCM通知