我正在撰寫 RESTful API，并且已經習慣了使用 HTTP 動詞進行不同操作的推薦協議。
但是，我不確定這些協議如何處理您洗掉可能很長的專案串列的情況。
似乎與 GET 一樣，DELETE 動詞沒有正文，因此僅限于 URL 的長度。那么你怎么能支持接受任意長的要洗掉的專案串列呢？
uj5u.com熱心網友回復：
從一開始....
HTTP是我們的自描述訊息標準，受統一介面約束。這反過來意味著網路上的每個人都以相同的方式理解 HTTP 請求。
換句話說
DELETE /api/users/5b45eda8-067c-42c1-ae1b-e0f82ad736d6
具有相同的含義
DELETE /www/home.html
在這兩種情況下，我們都要求服務器對其資源模型進行更改。
因為每個人都以相同的方式理解這些請求，所以我們可以創建通用組件（例如：快取）來理解通過網路域傳輸檔案中訊息的含義，因此可以做一些智能的事情（比如使以前快取的回應無效）。
即使通用組件對資源的語意一無所知，也對隱藏在資源背后的底層域模型一無所知，我們也可以做到這一點。
DELETE，在 HTTP 中，總是指定單個目標 URI；“批量洗掉”在這里不是一個選項。
（我還沒有找到任何描述對通用組件的批量洗掉的注冊 HTTP 方法。WebDAV 方法之一可能可以表達這些語意，但 WebDAV 標準也有很多其他包袱 - 我不會嘗試將這些方法重新用于“普通”API。）
因此，如果您嘗試洗掉 API 中的三個資源，那么您將需要三個請求來執行此操作——就像您嘗試洗掉網站上的三個頁面一樣。
也就是說，如果使用單個 HTTP 請求洗掉網站上的一堆資源比讓通用組件了解正在發生的事情更重要：您可以選擇使用 POST
POST 在 HTTP 中有許多有用的用途，包括“此操作不值得標準化”的通用目的。——菲爾丁，2009
通用組件會理解目標 URI 所標識的資源正在以某種方式發生變化，但不會理解有效負載中發生的事情。
理論上，您可以標準化一個有效負載，這意味著“我們正在洗掉所有這些資源”，然后可以實作通用組件來識別該標準。在實踐中，祝你好運。
現在，如果您想要的是批量洗掉域模型中的物體，那么您有一些可用的選項。
在網路上，我們通常會使用類似表單的東西——也許每個物體都有一個復選框。您選擇要洗掉的物體，提交表單，HTTP 請求處理程式決議訊息，然后將資訊轉發到您的域模型。
您可以使用遠程創作習語來實作類似的功能 - 這是一個資源，其表示是物體串列。您將洗掉了物體的該檔案的副本放入服務器，然后在服務器上對域模型進行更改以進行匹配。
這是一種非常宣告性的方法：“更改域模型，使資源的表示看起來像這樣”。
這類似于您如何使用 HTTP 修復網頁中的拼寫錯誤：在請求正文中發送帶有新 HTML（包括拼寫更正）的 PUT 請求。
PATCH 的想法非常相似：我們描述對資源表示的更改，然后服務器將該資訊傳遞給域模型。這里的區別在于，我們不發送整個表示，而是發送一個描述更正的補丁檔案。
如果您想要一種命令式方法 - 只需使用 POST
POST /Bob
Content-Type: text/plain
Bob,
Please delete domain entities 1, 2, 5, 7
通用組件不會理解您如何嘗試修改目標資源，但它們至少會知道這么多。
當有很多資源的表示依賴于相同的資源時，事情就會變得混亂。標準并沒有為我們提供太多的可供性方式來宣布“這里是所有已更改的資源”。
快取失效是兩個難題之一。HTTP 有一些適用于簡單情況的可供性，但當事情變得更復雜時，權衡就變得必要了。
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/385808.html