REST API Http 状态码最佳实践

Question

我们正在编写一个 REST API，它将被公开并被许多第三方开发人员使用。我正在研究 http 状态代码的最佳实践，尤其是在错误情况下。

我们的应用程序内部有很多组件，API 是它们的接口(interface)。如果内部组件有任何错误，我应该返回 500 并带有适当的错误消息吗？

在浏览 SO 时，我发现了一些博客/SO 线程，它们提出了不同的方法，但没有一个给出具体的答案。

非常感谢您对此的任何帮助。

Answer 1

这是非常主观的。这是我的意见，编写了几个中等复杂的 API。

意识到 HTTP 状态代码不会巧妙地映射到您的内部组件将返回的错误类型。他们不是设计来的。

遵循的基本规则是 200 是可以的，其他都是错误的。

我基本上只使用这 4 个非 OK 状态代码:

400 = 错误请求。调用者发送了无效的请求参数。
401 = 未经授权。调用者没有发出请求的权限。
404 = 未找到。调用者请求的资源无法找到或不存在。
500 = 内部服务器错误。其他一切。发生了一些不好的事情，调用者可能对它无能为力。

就我而言，这就是 HTTP 状态代码。

但我不止于此。我总是返回一个 JSON 响应，其中包含我自己的错误代码、消息以及——在测试环境中——堆栈跟踪。我的错误代码是调用者可以根据需要对其进行编程的数字。就我而言，这是真正的错误代码。