例如我需要设计一个具有两个功能的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规则或这种情况的常规做法？
[我建议您创建2个端点，这通常在UsaEPay，Stripe等支付服务提供商之间完成
[第一个端点将是：POST .../authorize，它将收到进行付款所需的所有信息，例如金额，付款人信息和付款方式信息，然后它将创建一个paymentAuthorization并返回其状态如果授权成功，则以authorizationToken开头。
第二个端点类似于：POST .../capture，在此端点中，您将仅查找与之前生成的paymentAuthorization相关的authorizationToken并继续进行付款
也可以看一下Stripes文档https://stripe.com/docs/api/payment_intents，以了解有关这种系统结构的更多信息
虽然不是严格禁止的，但是GET请求通常没有请求正文：HTTP GET with request body，因此我不会使用解决方案1。
在我们的API（也包括付款API）中，我们使用具有相同URL的查询参数来标记空运行（或在我们的域术语中为forecast），就像您的解决方案2，并且此处描述：Dry run strategy for REST API。它会返回与错误情况下非预测请求将产生的错误代码和消息相同的错误代码和消息。
由于我们使用被动付款处理器，因此我们需要这样做，但是只有在预付款成功后，它才会启动。该过程开始后，该过程会立即将该预测结果作为响应返回给用户，从而提高了UI的响应度。实际付款将花费一秒钟的时间进行实际处理，因为某些支票会与其他服务进行反应。它甚至可能失败，最终用户将收到有关最终状态的通知，但这很少见。
如果检查HTTP规范，POST处理资源的方式是相当随意的，则无需对任何内容进行永久更改：https://tools.ietf.org/html/rfc7231#section-4.3.3
POST方法要求目标资源处理根据资源的要求包含在请求中的表示形式自己的特定语义
[...]
如果已在原始服务器上将一个或多个资源创建为成功处理POST请求的结果，原始服务器应该发送包含Location标头的201（已创建）响应为创建的主要资源提供标识符的字段（第7.1.2节）和描述状态的说明请求，同时引用新资源。
只需确保记录查询参数。
Stripe API有点不同，因为如果您发送请求，它将被预订，就不会空运行（/capture调用是由付款人而不是付款人调用的，因此这是另一个用例）。