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
}

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

1. 如果转移成功,则确定转移(例如,如果账户A中的余额较低,则可能会失败)
2. 确定预先适用的费用

那么,"干跑"概念的最佳实践是什么？我可以想到几个选择:

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

这些是我对此事的看法,但我喜欢听别人的想法.

Answer 1

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

在选项 1 和 2 之间进行选择取决于您的 API 的喜好和细节。目前尚不清楚/dry-run-transaction将 a视为一种独立的事物而不是交易的合理性。

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

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

我认为根本不涉及安全问题。如果您真的很担心，只需将execute: false选项 1 设为默认值即可。

另一种方法可能是使用端点/transactions和/transaction-results. 如果您发布到/transaction，您将执行交易并获得永久交易结果的 ID/结果。如果你 POST 到 /transaction-results，你会得到一个没有 id 的响应和交易的临时结果集。请注意，我已经考虑了整整 20 秒，因此可能存在我没有看到的明显问题。:-)