0

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

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

OrderProduct(CustomerID, ProductID, Quantity)

这个会

  • 创建订单数据库记录
  • 减少产品数据库记录中的可用库存
  • 在 Worklist 表中创建一个条目以进行选货

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

在我的 REST 方法中，我已经拥有 Customer、Product 和 Worklist 的 POST 端点，但我现在需要在一个事务中组合对所有 3 个端点的调用。我的问题是在插入工作列表因任何原因失败的情况下能够回滚。

那么创建一个仅公开 POST 的 ProductOrder 端点是否合适？

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

我的紧张就在身边

  1. 不重新使用我已经公开的实体端点。
  2. 发明一个实体只是为了处理 RPC 类型调用（因此只实现 POST）

谢谢，安迪

4

1 回答 1

0

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

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

不重新使用我已经公开的实体端点。

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

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

这就是重点。您有一个“订单”实体，您可以对其进行“获取”、“发布”、“放置”或“删除”。这个想法是您可以使用 GET /customers/{id}/orders 获取客户总订单，或者使用 /orders/{id} 或 /customers/{id}/orders 获取有关特定订单的详细信息/{id} 甚至使用 POST /customers/{id}/orders 创建新订单。

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

于 2013-07-26T14:08:20.543 回答