微服务 HttpStatus 代码

Question

这是一个与微服务架构中各种 API 之间的通信信号良好实践相关的问题。

我面临以下“事件”：

我需要找到一种更好的方法来通过使用 HTTP 状态代码和各种有效负载来发出这些信号，详细解释正在发生的情况。

例如：

有什么想法吗？我对我的临时解决方案并不是 100% 满意。想让它变得更好。我知道这里有两种动物：一种是客户端-服务器信号，第二种与数据相关（有效负载丢失等）

Answer 1

一个微服务已关闭（物理上） - 我可以使用 NOT_FOUND (404) 和有效负载：API_DOWN

在这种情况下，您将无法控制消费者收到的响应代码。根据服务的托管和管理方式，您可能会收到 500 服务器错误、502 网关错误、503 不可用或 504 超时中的任何一条。但是，您将获得什么取决于您的基础设施和堆栈设置。

一个微服务正在使用错误的 URL 调用另一个微服务 - 我可以使用 BAD_REQUEST (400)

这在语义上与上述情况相同。尝试调用不可用的服务与尝试调用不存在的服务之间没有什么区别。

一个微服务正在使用正确的 URL 但错误的参数调用另一个微服务（例如查询参数，或 POST 正文验证失败） - 我还可以将 BAD_REQUEST (400) 与验证负载消息一起使用

这有几个变体。例如，一种是对仅支持 PATCH 的资源调用 PUT。在这种情况下，有一个状态代码，它是 405 Method not allowed。同样，您通常无法控制这里 - 如果您没有针对给定资源定义请求的操作，大多数服务框架都会自动将此状态代码返回给使用者。

另一种变体（如您的示例中）是不正确的查询参数。同样，在这种情况下，大多数框架将自动返回 400 Bad request（或 422 Unprocessable）。如果提供了查询参数但在其他方面无效，则 400 Bad request 是合适的。

注意：对于“无效”路径参数返回 400 Bad 请求通常不合适。

一个微服务正在向另一个微服务请求资源，并且在数据库中找不到该特定资源（比如说 findById 类型） - 我还可以将 NOT_FOUND (404) 与 RESOURCE_NOT_FOUND 消息一起使用

是的，404 Not found 是正确的状态代码。

如果由未捕获的异常引起，其他一切都可能是 INTERNAL_SERVER_ERROR。

不必要。我经常使用的一个状态代码是 409 冲突，适用于输入正常但导致某种问题（例如重复实体）的情况。

200 OK 好东西

在很多情况下 200 就足够了。但是，如果添加了某些内容，请考虑 201 Created；如果调用没有效果，请考虑 202 Accepted（例如，如果您尝试创建资源，但资源已经存在）；如果您想显式调用不返回，请考虑 204 No Content类型应该是预期的。

总的来说，这是一个很好的答案，但是“405 Method Not allowed”不适合错误的查询字符串或正文内容；它指的是发送错误的*方法*，例如当只允许“GET”时发送“POST”。有时，“422 Unprocessable Entity”可能是合适的，但通常您只需要“400 Bad Request” (2认同)