【问题标题】:HTTP Code for payment accepted/refused in a REST APIREST API 中接受/拒绝付款的 HTTP 代码
【发布时间】:2015-08-08 04:56:31
【问题描述】:

在 REST API 中,在支付方式(用户提供他的卡信息)中,如果支付失败我应该返回 200(卡过期或余额太低问题)并附加消息 + 自定义JSON 中的其他错误代码?或者还有其他的 HTTP 代码吗?

我没有找到任何关于这个特殊案例的信息,我只是找到了支付的 402 代码,但它似乎不是为这个案例设计的。我不是在谈论服务器(500)错误或无法访问的银行,只是由于用户卡导致的支付问题。

【问题讨论】:

  • 不知道为什么被否决,请添加评论。

标签: api rest http


【解决方案1】:

“付款失败”究竟是什么意思?我可以想到几种不同的场景,其中许多可能需要不同的状态代码来反映实际状态。

不过,这完全取决于您的 API 的其余部分如何工作。如果您已经在响应正文中使用 JSON 对象,您也可以为任何操作报告 200 OK:

HTTP/1.1 200 OK
...

{ 
    success: false,
    message: "Balance too low"
}

如果您不想这样,任何适用的 4xx 或 5xx 错误都可以。尝试搜索。

【讨论】:

  • 好的,谢谢:)。 “‘付款失败’到底是什么意思?”任何情况(服务器错误 500 除外)。我的问题是关于一般的付款失败。原因将在带有自定义错误代码的 JSON 消息中,但问题只是关于 HTTP 代码
  • 那么,请查看链接的问题并进行更多搜索。关于在什么情况下使用哪个状态码有很多讨论。 必须决定哪个 HTTP 状态代码是合适的。当支付提供商宕机时,您是否希望返回与用户余额不足时相同的代码?去阅读并选择任何一个。
  • 好的。我知道有很多关于状态码的讨论。抱歉,如果我的问题不清楚。我知道 API 可以在错误请求时发送 400 或在未找到资源时发送 404,但是对于拒绝付款(余额太低、卡无效等),我不知道应该使用哪一个。 会在“无效卡”上选择哪一个?我也会编辑我的问题。
【解决方案2】:

我认为你应该使用406 代码。

Code - 406

Message - Not Acceptable

Description - Insufficient funds or other payment problem.

【讨论】:

  • 不可接受具体涉及与AcceptAccept-LanguageAccept-Encoding 请求标头相关的失败,因此这是不正确的。
猜你喜欢
  • 2018-08-13
  • 1970-01-01
  • 2016-07-26
  • 2016-05-20
  • 2014-08-31
  • 2013-04-04
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多