如何使用RESTful方式對CANCEL操作進行建模？

Question

我們目前正在從我們的龐然大物中爭取更小的服務。我們的域名與票務系統非常相似。我們決定從域名的取消過程開始。

我們的取消服務有一個簡單的端點「取消」，它包含了票證的ID。在內部，我們檢索id，執行一些與取消相關的操作並更新存儲中實體的狀態。從商店的角度來看，被取消的機票和現場機票之間的唯一區別是幾個屬性。

從我讀過的，PATCH似乎是在這種情況下使用正確的動詞，因爲只更新資源中的一個簡單屬性。

PATCH /api/tickets/{id} 
Payload {isCancelled: true} 

但isCancelled不是實體中的實際屬性。在有效載荷中發送不屬於實體的屬性是否公平？還是應該考慮對此請求進行建模的其他形式？我不想發送整個實體作爲有效載荷的一部分，因爲它很大。

我已經考慮過創建一個新的資源CancelledTickets，但在我們的域中，我們永遠不需要在取消票據上獲取GET。因此，不必創建新的資源

任何幫助，將不勝感激

感謝 ķ

Answer 1

看看究竟是什麼RESTful way敬而遠之。無論您是否發送PATCH請求isCancelled作爲有效負載，或者即使DELETE如果您想要票證消失。它仍然是RESTful。

你的舉動取決於你的需求。至於你說的

我已經考慮創建一個新的資源CancelledTickets，但在我們 領域，我們永遠不會有必要在取消門票GET。

我只是發送DELETE。你不需要物理移除它。如果可以取消，則執行isCancelled機制。這只是品味的問題。

Answer 2

暴露資源的GET接口不是強制性的。

例如，使用

PUT /api/tickets/{id}/actions/cancel 

提交取消請求。我選擇PUT，因爲不會有一個以上的取消請求生效。

希望它有幫助。