这种交易方式是否完整？

简化我的用例，但我想创建一个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

这种交易方式是否完整？

回答

相关问题