这个问题与微服务架构中各种 API 之间的通信信号良好实践相关。
我面临以下“事件”：
我需要找到一种更好的方法来通过使用 HTTP 状态代码和各种有效负载来发出信号，详细解释正在发生的情况。
例如：
有什么想法吗？我对我的临时解决方案并不是 100% 满意。想让它变得更好。我知道这里有两种动物：一种是客户端-服务器信号，第二种与数据相关（有效负载丢失等）
一个微服务已关闭（物理上） - 我可以使用 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 未找到是正确的状态代码。
如果由未捕获引起，则其他所有情况都可能是 INTERNAL_SERVER_ERROR 例外。
不一定。我经常使用的一个状态代码是 409 冲突，适用于输入正常但导致某种问题（例如重复实体）的情况。
200 好东西就OK了
200 在很多情况下都可以。但是，如果添加了某些内容，请考虑 201 Created；如果调用没有效果，请考虑 202 Accepted（例如，如果您尝试创建资源，但资源已经存在）；如果您想显式调用不返回，请考虑 204 No Content类型应该是预期的。
只是@tom-redfern 已经说过的一点补充。 有一张我喜欢的漂亮地图。看起来像是地下的计划。
在图像的右下角，您有很好的摘要。
您可以将鼠标悬停在状态代码上并获得简短的解释。也许这对您的实施有所帮助。
例如，我们几乎在同一时间多次收到相同的请求。这会导致我们的弹性搜索中出现重复的条目。我们添加了一个 servlet 过滤器，它可以捕获重复项并返回 409 CONFLICT 状态代码。
409 的描述如示例：
表示请求因冲突而无法处理 在请求中，例如多个的情况下出现编辑冲突 更新。