rest - REST API 的试运行策略

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 余额不足，可能会失败)

预先确定适用的费用是多少

那么，“试运行”概念的最佳实践是什么？我能想到几个选择:

传旗到现有的传输端点以指示试运行选项。该标志可以是查询字符串、有效负载的一部分、 header 等。确切的实现有待商榷，但从概念上讲，我喜欢这个，因为它提供了一个干净的接口(interface)，让您了解有关从单个执行传输的所有信息端点。

专用端点 专门用于执行转移空运行。这“感觉”更安全，因为您不会无意中执行破坏性操作，因为实时和空运行端点是完全分开的。另一方面，如果你可以访问生产系统，你真的应该知道你在做什么，所以我不是一个 super 粉丝。

没有空运行概念 .只需使用一组完全不同的端点来计算费用、获取余额或任何其他有助于推断转账结果的操作。我不喜欢这样，因为您强制客户端复制传输端点中已包含的所有逻辑。

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

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/result。如果你 POST 到/transaction-results，你会得到一个没有 id 的响应和一个交易的 transient 结果集。请注意，我已经考虑了整整 20 秒，因此可能存在我没有看到的明显问题。 :-)