例如。我需要设计一个具有两个功能的 API:支付验证和支付创建。 我需要两者，因为最终用户在实际确认付款创建之前应该知道一切正常。 对于创作我有
POST .../payment
带有输入主体。如果出现问题，它会返回 HTTP 400。
验证(或模拟)执行与创建完全相同的过程，在持久化数据之前停止该过程。对于这个验证，最好有类似的东西吗
解决方案一
GET .../is-payment-ok
还有一个输入主体。它返回 HTTP 200，包括一个 bool 值答案和一些详细信息。
这里的资源不是支付，而是关于支付有效性的信息，这对我来说似乎是 REST 兼容的。缺点是 API 的用户可能会感到困惑，因为如果支付无效，那么模拟将返回 HTTP 200(正文中的 bool 值设置为 false)，而创建将返回HTTP 400。
，或者
方案二
POST .../payment?simulation=true , or
POST .../payment-simulation
此处的 HTTP 响应代码与创建付款时完全相同。缺点是我们使用 POST，实际上没有“发布”任何资源。
你会怎么做？这种情况是否有 REST 规则或常见做法？
最佳答案
虽然没有严格禁止，但 GET 请求通常没有请求主体:HTTP GET with request body ，所以我不会选择解决方案 1。
在我们的 API(也包括支付 API)中，我们使用具有相同 URL 的查询参数来标记试运行(或我们领域术语中的预测)，就像您的解决方案 2 ，如此处所述:Dry run strategy for REST API .它返回与非预测请求在出现错误时会产生的相同的错误代码和消息。
我们需要这个，因为我们使用了一个响应式(Reactive)支付处理器，但它只有在支付预测成功时才会启动。该流程在流程启动后立即将此预测结果作为响应返回给用户，从而提高了 UI 的响应度。实际付款将需要一秒钟才能发送以进行实际处理，因为一些支票是通过其他服务被动完成的。它甚至可能会失败，最终用户会收到有关最终状态的通知，但这种情况非常罕见。
如果您查看 HTTP 规范，POST 处理资源的方式相当随意，无需对任何内容进行持久更改:https://www.rfc-editor.org/rfc/rfc7231#section-4.3.3
The POST method requests that the target resource process the representation enclosed in the request according to the resource's own specific semantics
[...]
If one or more resources has been created on the origin server as a result of successfully processing a POST request, the origin server SHOULD send a 201 (Created) response containing a Location header field that provides an identifier for the primary resource created (Section 7.1.2) and a representation that describes the status of the request while referring to the new resource(s).
只需确保记录查询参数。 编辑: Kubernetes 做到了:https://kubernetes.io/docs/reference/using-api/api-concepts/#dry-run
Stripe API 有点不同，因为如果您发送一个请求，它将被预订，没有试运行(/capture 调用由金钱请求者调用，而不是付款者，所以这是另一个用例)。
关于rest - 您将如何设计包含 POST 模拟的 REST API？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/58831345/