这个交易是否接近REST-ful？

Question

简化我的用例，但我想创建一个REST服务来处理客户订单。

在RPC世界中，我将创建一个RPC端点

OrderProduct(CustomerID, ProductID, Quantity)

这会

• 创建订单数据库记录
• 减少产品数据库上的可用库存 记录
• 在工作清单表格中创建一个用于选股的条目

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

在我的REST方法中，我已经为客户，产品和工作列表提供了POST端点，但我现在需要在单个事务中将所有3的调用组合在一起。我的问题是，如果插入工作列表因任何原因失败，就能够回滚。

创建仅暴露POST的ProductOrder端点是否合适？

在处理POST的服务中，我创建了一个数据库事务，并直接与数据库交互，以更新我关注的三个表。

我的紧张情绪在附近

1. 不重复使用我已经公开过的实体端点。
2. 创建一个实体只是为了处理RPC类型调用（因此只是 实施POST）

谢谢， 安迪

Answer 1

TLDR：别担心！考虑概念实体，而不是RPC。如有疑问，请使用GET，POST以及可选的PUT和DELETE创建一个新的RESTful实体。

你大多是正确的，你会想要一个“ProductOrder”端点，虽然我只称它为'Order'。由于您拥有“订单”数据库记录，因此将其公开给与系统中其他实体相同的REST工作流是有意义的。

  

不重复使用我已曝光的实体端点。

没有理由。产品和客户REST端点无法帮助您创建订单，因为订单本身是系统中的概念实体，可能包含跨越复杂生命周期的许多不同步骤（验证订单，跟踪订单状态，减少库存，转移资金） ）。您的REST客户端不应该知道每一步，它应该只知道创建一个订单需要POST到Order端点。

  

创建一个实体只是为了处理RPC类型调用（因此只实现POST）

这就是重点。你有一个“订单”实体，你可以'GET'，'POST'，'PUT'或'DELETE'。我们的想法是，您可以使用GET / customers / {id} / orders获取客户总订单，或使用/ orders / {id}或/ customers / {id} / orders获取有关特定订单的详细信息/ {id}甚至可以使用POST / customers / {id} / orders。

创建新订单

订单成为一个实体，您可以从中应用所有标准RESTful操作。