A) 當購買購物車的內容時，將購物車復制到固定訂單并洗掉購物車。
B) 如果下訂單將被更改，則會創建一個允許編輯訂單的購物車。（取消可能會導致取消費用）。接受更改后，更改將從購物車傳輸到訂單。購物車將再次被洗掉。
我正在努力使用資源在 RESTful API 中對這些狀態變化進行建模嗎？我將如何表達資源的變化？購買購物車內容會洗掉購物車并創建一個新購物車。這里有一些想法......
a) 創建訂單：
POST Orders?cart=cartId 或 PATCH Cart/:id {狀態：已購買}
（回應將包含指向 Orders/:newid 的鏈接）
b) 保存現有訂單的更新購物車：
PUT Orders/:id?cart=cartId 或 PATCH Cart/:id {status: changeConfirmed} 或 PUT Orders/:id/:cartID
uj5u.com熱心網友回復：
啟發式：想想你會如何在網路上做到這一點。
您正在查看一個描述購物車內容的網頁。在同一頁面上是“下訂單”表格。當您提交該表單時，瀏覽器會向您的 Web 服務器發送一個 HTTP POST 請求，以表單的操作元資料描述的任何資源為目標。這會觸發 HTTP 門面背后的一些業務活動，操縱域模型中的購??物車和訂單物體。
您正在查看描述您的訂單的網頁。在同一頁面上是“編輯訂單”表單。當您提交該表單時，瀏覽器會向您的 Web 服務器發送 HTTP POST 請求，以表單操作元資料描述的任何資源為目標。這會觸發 HTTP 門面背后的一些業務活動，操作域模型中的購??物卡和訂單物體。
那就是 REST。
請求目標可以是你想要的任何東西；但是通過網路傳輸檔案的通用目的是使用請求目標進行快取和快取失效。這意味著如果您巧妙地選擇您的請求目標，您可以確保成功的請求使資源的陳舊副本無效。
對于您的第一個示例，Place Order 請求將更改的明顯資源是購物車資源本身，因此這是對表單操作應該是什么的合理初步猜測。
在第二個示例中，訂單資源是合理的第一次猜測。
必須是POST嗎？不 - 您可以使用 PUT 代替，效果類似；客戶端將編輯過的資源副本發送回服務器 (PUT)，然后服務器觸發業務活動。
（PATCH 是 PUT 的替代方案，在這種情況下，我們不是發送整個檔案，而是以服務器已公布的、可以理解的形式發送編輯的描述；對于具有 JSON 表示的資源，我們通常會使用類似JSON Patch 的東西或JSON 合并補丁）。
創建訂單
PATCH /Cart/12345 HTTP/2
Content-Type: application/merge-patch json
{ "status": "purchased" }
保存現有訂單的更新購物車
PATCH /Cart/12345 HTTP/2
Content-Type: application/merge-patch json
{"status": "changeConfirmed" }
兩者都非常合理。PUT - 包括帶有更改的 /Cart/12345 表示的完整副本 - 如果該檔案不是太大（與 HTTP 標頭相比）可能是更好的答案：如果 HTTP 回應為，則可以重試具有冪等語意的請求在不可靠的網路上丟失。
請注意，即使目的是觸發兩個不同的業務活動，HTTP 方法和請求目標也可以相同。這在 REST 中是完全正常的（但不一定常見 - 您服務器的 HTTP 路由框架可能無法區分這兩種情況，因此您必須撰寫一些定制代碼來觸發正確的活動）。
轉載請註明出處，本文鏈接：https://www.uj5u.com/qiye/341006.html
標籤：休息
上一篇：SpringBoot集成測驗。如何測驗“洗掉”方法？
下一篇：格式化來自API的資料