Question

我正在寻找REST API“干运行”操作的最佳实践。

假设我有一个端点，将资金从账户A转移到账户B.我可以像这样开始转账：

POST /transactions
{
  "amount": 1000,     // how much to transfer
  "source": "A",      // account to transfer from
  "destination": "B"  // account to transfer to
}

此操作会创建一个“事务”，因此响应将是一个事务对象，其有效负载包含：

{
  "id": "txn-123",
  "amount": 1000,
  "source": "A",
  "destination": "B",
  "fees": 10,          // any fees that were charged
  "balance": 2500      // balance in source account AFTER transfer
}

我希望能够在几个原因下进行干跑：

判断转移是否成功（例如，如果帐户A的余额较低，则可能会失败）
确定预先适用的费用

那么，“干跑”概念的最佳实践是什么？我可以想到几个选择：

将标记传递给现有传输端点以指示干运行选项。标志可以是查询字符串，有效载荷的一部分，标题等。确切的实现有争议，但从概念上讲我喜欢这个，因为它提供了一个干净的界面，让您知道从单个执行传输所需要知道的所有内容端点。
专用端点专门用于执行传输干运行。这种“感觉”更安全，因为您不会无意中执行破坏性操作，因为实时和干运行端点是完全分离的。另一方面，如果你有权使用生产系统，你真的应该知道你在做什么，所以我不是一个忠实的粉丝。
没有干涸的概念。只需拥有一组完全不同的端点来计算费用，或获得平衡，或任何其他可帮助您<推断转移结果的操作。我不喜欢这样，因为你强迫客户端复制已经包含在传输端点中的所有逻辑。

到目前为止，这些是我对此事的看法，但我很高兴听到其他人的想法。

Answer 1

选项3显然是错误的。你无缘无故地迫使客户做额外的工作。

选项1和2之间的选择取决于品味和API的细节。目前尚不清楚将/dry-run-transaction视为一种独立于交易的事物是多么合理。

如果选择选项2，请考虑将/dry-run-transaction作为短期资源，或者根本不保留它。这样客户可以通过POST查看费用，节省存储空间。

如果您使用选项1，我认为技术上最正确的选项是在有效负载中包含一个属性，例如execute: false。这会将所有信息返回给客户端，并允许他们使用execute: true对事务执行PUT以完全按原样提交。这种方法的一个缺点是你会有一堆未执行的事务（永远？），因为人们会在看到结果后决定不执行它们。

我认为安全根本没有进入讨论。如果你真的很担心，只需将execute: false作为选项1的默认值。

另一种方法可能是使端点/transactions和/transaction-results。如果您发布到/transaction，则执行该事务并获取永久交易结果的ID /结果。如果您POST到/ transaction-results，则会得到一个没有id的响应以及该事务的一组瞬态结果。注意我已经考虑了这20秒，所以可能会有一个明显的问题，我还没有看到。： - ）

Answer 2

恕我直言，我不认为 POST 应该用于试运行。 Dry run 具有幂等语义，因为它不会改变系统的状态，这与 POST 相矛盾。另一方面，PUT 虽然幂等也不是一个好的选择，因为它意味着状态改变。如果我们真的想要 REST-full，那真的让 GET 成为唯一的选择。因此我会创建一个单独的 REST 点：

GET /transactions/dry-run

在 URL 中嵌入 {amount, source, and target}，如下所示：

GET /transactions/dry-run?amount=100&source=A&target=B

REST API的干运行策略

2 个答案: