处理服务层中的远程 api 验证错误

Question

假设有一些管理器类与远程服务对话，例如，与可以创建新用户和更新现有用户配置文件的用户微服务对话。这个管理器类在代码中无处不在：在控制器和其他类中。在与远程服务交谈之前，我们的经理类不知道提交的 DTO 是否有效。问题是：如果远程服务返回验证错误，下一步该怎么做？如何处理这个错误？我已经考虑过了，并且有一些选择：

• 验证失败时抛出异常
• 将收集验证错误的 Errors 对象传递给管理器
• 在管理器类中创建方法 getLastErrors()

也许还有其他更好的解决方案？

附言假设远程服务返回 JSON 格式的错误，不管是 JSON-RPC、SOAP 还是 REST 微服务。

Answer 1

除非您想将服务错误转换为不同的东西，或者甚至处理它们以在客户端层中做出某些决定，否则服务错误通常会以人类可读的方式格式化以显示在 UI 中，让用户知道什么出错了。

另一方面，如果没有 UI，则应该有一个 logger。就像您在 UI 层中所做的那样，您将格式化这些错误并将它们记录到文件或任何其他存储方法中。

另外，您可能想了解更多关于fail-fast concept 的信息：

在系统设计中，快速故障系统是一种能够立即报告的系统 在其界面上可能指示失败的任何情况。 快速故障系统通常旨在停止正常运行，而不是 而不是试图继续一个可能有缺陷的过程。这样的设计经常 在一个操作的几个点检查系统的状态，所以任何 可以及早发现故障。故障快速模块通过 处理错误但不检测错误的责任 系统的下一个最高级别。

OP 对此进行了注释：

如果从微服务返回验证错误，哪个管理器 上课应该怎么办？抛出异常或将这些错误放入某些 类中的字段？

关于这个问题，我得出了一些结论，那就是整个流程应该通过一个专门的 DTO，我称之为 accumulated result (check the full description)：

表示一个多用途的正交实体，它同时传输 调用操作的结果以及有用的信息 调用者喜欢状态、状态描述和有关实际的详细信息 整个操作的结果。

这样，即使在多层架构中，每一层/层都可以向累积结果添加更多信息或做出决策。

可能有些人可能会争辩说您应该抛出异常，但我不认为违反规则是异常，而是预期的用例。

Answer 2

如何处理来自远程服务的验证错误？

返回相关的HTTP status code，以及响应正文中所需的尽可能多的信息（有时没有）。

它是 SOAP 还是 RESTful 并不重要，想象一下 JSON 返回响应

服务的类型将决定您的故障处理方法。对于 SOAP 服务，您应该返回 SOAP fault。