您将如何设计包含 POST 模拟的 REST API？

Question

例如。我需要设计一个具有两个功能的 API：付款验证和付款创建。我需要两者，因为最终用户应该在实际确认付款创建之前知道一切正常。为了创造，我有

POST .../payment

带有输入体。如果出现问题，它会返回 HTTP 400。

验证（或模拟）执行与创建完全相同的过程，在保存数据之前停止该过程。对于这个验证，最好有类似的东西

解决方案1

GET .../is-payment-ok

还有一个输入体。它返回 HTTP 200，包括一个布尔值答案和一些细节。

这里的资源不是付款，而是关于付款有效性的信息，这对我来说似乎是 REST 兼容的。缺点是 API 的用户可能会感到困惑，因为如果付款无效，那么模拟将返回 HTTP 200（主体中的布尔值设置为false），而创建将返回 HTTP 400。

， 或者

解决方案2

POST .../payment?simulation=true , or
POST .../payment-simulation

这里的 HTTP 响应代码与支付创建完全相同。缺点是我们使用 POST，实际上没有“发布”任何资源。

你会怎么做？这种情况下是否有 REST 规则或惯例？

Answer 1

虽然不是严格禁止的，但 GET 请求通常没有请求正文：HTTP GET with request body，所以我不会选择解决方案 1。

在我们的 API（支付 API）中，我们使用具有相同 URL 的查询参数来标记试运行（或在我们的域术语中预测），就像您的解决方案 2 一样，如下所述：REST API 的试运行策略。它返回与非预测请求在发生错误时产生的相同错误代码和消息。

由于我们使用了反应式支付处理器，因此我们需要它，但它仅在支付预测成功时才启动。该流程在流程开始后立即将此预测结果作为对用户的响应返回给用户，从而增加了 UI 的响应能力。实际付款将需要一秒钟才能发送以进行实际处理，因为某些检查是与其他服务反应完成的。它甚至可能会失败，最终用户会收到有关最终状态的通知，但这种情况非常罕见。

如果您检查 HTTP 规范，POST 处理资源的方式非常随意，则无需对任何内容进行持久更改：https : //tools.ietf.org/html/rfc7231#section-4.3.3

POST 方法请求目标资源根据资源自身的特定语义处理请求中包含的表示

[...]

如果作为成功处理 POST 请求的结果在源服务器上创建了一个或多个资源，则源服务器应该发送一个 201（已创建）响应，其中包含一个 Location 头字段，该字段为所创建的主要资源提供标识符（第 7.1 节） .2) 以及在引用新资源时描述请求状态的表示。

只需确保记录查询参数即可。编辑： Kubernetes 做到了：https : //kubernetes.io/docs/reference/using-api/api-concepts/#dry-run

Stripe API 有点不同，因为如果您发送请求，它将被预订，没有空运行（/capture调用是由付款请求者而不是付款者调用的，因此它是另一个用例）。