1

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

请求格式正确，我无法返回 4xx 失败，但应用程序的逻辑要求我返回不同的错误消息。

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

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

现在的问题是，如果没有标准代码喜欢Conflict或没有NotFound意义，我应该在这种情况下使用哪种 HTTP 状态代码。

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

4

1 回答 1

-4

请参阅 RFC 7231：

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

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

剩下最后一个认真的候选人，

500内部服务器错误

500（内部服务器错误）状态代码表示服务器遇到了阻止它完成请求的意外情况。

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

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

于 2019-03-11T16:16:21.423 回答