API设计中的业务错误应该使用哪个HTTP状态代码？

Question

假设我有一个API端点执行某些业务操作，这可能导致许多不同的故障直接与请求连接。

请求正确形成，我不能返回4xx失败，但应用程序的逻辑指示我返回不同的错误消息。

现在，我希望客户端能够区分这些错误消息，以便根据代码采取不同的操作。我可以返回这样的自定义JSON，例如

{
  "code": 15,
  "message": "Some business error has occurred"
}

现在的问题是，如果没有像Conflict或NotFound这样的标准代码有意义的话，我应该使用哪些HTTP状态代码。

似乎500 InternalServerError是合乎逻辑的，但是我怎么能另外标记这不能重试，如果只是记录给定状态代码是不可能重试所以如果你没有得到其中一个可以重试？

Answer 1

咨询RFC 7231：

503服务不可用看起来像一个潜在的候选人，但RFC提到这应该代表一个问题“这可能会在一段延迟后缓解”。这将向客户表明它可以稍后尝试相同的呼叫，可能是在工作时间之后或在周末。这不是你想要的。

501 Not Implemented是可能的，但RFC提到“当服务器无法识别请求方法并且无法为任何资源支持时，这是适当的响应。默认情况下，501响应可缓存;”这似乎不是这里的情况 - HTTP方法本身可能是有效的 - 这里的失败似乎发生在业务规则层（例如，发送不在数据库中的帐号），而不是HTTP方法（GET，POST等），你从来没有实现过。

这留下了最后一位认真的候选人

500内部服务器错误

500（内部服务器错误）状态代码表示服务器遇到意外情况，导致服务器无法完成请求。

这是通常用于通用“应用程序中发生的异常”情况的错误代码。 500是最好的选择。

至于如何将其与“时间内部故障”错误区分开来，您可以将其作为HTTP body的一部分包含在内 - 只需确保您的客户端可以解析自定义代码！