這種交易方式是否完整？

簡化我的用例，但我想創建一個REST服務來處理客戶訂單。這種交易方式是否完整？

在RPC世界，我將創建一個RPC端點

OrderProduct(CustomerID, ProductID, Quantity)

在產品DB 記錄這

創建一個訂單數據庫記錄
遞減可用庫存
創建進入工作清單表中進行篩選

（不是我真正的用例，但比我在做什麼更容易理解）

在我的REST方法我已經有客戶，產品和工作列表POST終點，但我現在需要調用結合起來，所有3在一次交易中。我的問題是有能力在插入工作列表失敗的情況下出於任何原因回滾。

那麼創建僅展示POST的ProductOrder端點是否合適？

在處理POST的服務中，我會創建一個數據庫事務並直接與數據庫交互以更新我所關心的三個表。

我太緊張，大約是

不是我已經暴露了實體端點重新使用。
發明了實體公正處理的RPC調用類型（因此只執行POST）

感謝，安迪

來源

2013-07-26 AndyH

嗯，我不太確定問題是什麼......如果你想創建一個端點來使用post命令一個結合了3件事情的產品，那麼我會說這是可以接受的。只要確保你有一個回滾過程，以防止一個步驟失敗。應該很容易做到這一點。根據你的數據庫你可能會做所有的數據庫方面，觸發器和sps包裝在一個事務中，以防萬一發生故障，所以你可以將其回滾。但它的代碼非常可行。 –

TLDR：別擔心！根據概念實體思考，而不是RPC。如果有疑問，請使用GET，POST和可選的PUT和DELETE來創建一個新的RESTful實體。

你基本上是正確的，你會想要一個「ProductOrder」端點，但我只是把它稱爲'Order'。由於您擁有「訂單」數據庫記錄，因此將其與系統中的其他實體展示給相同的REST工作流程是有道理的。

不重新使用我已經公開的實體端點。

沒有理由。產品和客戶REST端點無法幫助您創建訂單，因爲訂單本身就是您系統中的概念實體，可能涵蓋跨越複雜生命週期的許多不同步驟（驗證訂單，跟蹤訂單狀態，減少庫存，轉移資金）。您的REST客戶端不必知道每一步，它應該只知道創建一個訂單需要POST訂單端點。

發明了實體公正處理的RPC調用類型（因此只執行POST）

這就是那種點。你有一個'訂單'實體，你可以'GET'，'POST'，'PUT'或'DELETE'。我們的想法是，您可以通過使用GET/customers/{id}/orders獲得客戶總訂單，或者使用/ orders/{id}或/ customers/{id} /訂單獲取特定訂單的詳細信息/ {id}，甚至使用POST/customers/{id}/orders創建新訂單。

訂單變成可以應用所有標準RESTful操作的實體。

來源

2013-07-26 14:08:20

感謝兩位評論。將得到編碼.... – AndyH

這種交易方式是否完整？

回答

相關問題