SOAP错误或结果对象？

Question

我和同事正在讨论这个问题，我们无法达成协议，所以我想得到你的想法。我对此有自己的看法，但我不会为你破坏它。

我应该何时返回 SOAP错误，何时应该返回包含错误信息的结果对象？假设这是一个可以被各种系统（.NET，Java，等等）使用的通用Web服务。结果对象将具有isError标志，errorType（类似于特定的异常类型）和消息。

需要考虑的一些要点：

1. 数据验证错误是否是错误？
2. 是否存在故障组合（对于非常特殊情况）和结果对象（对于“预期”错误）？
3. 您如何对SOAP错误进行分组（关键[空引用]与验证[邮政编码不正确]）？
4. 快速失败与必须记住检查错误
5. 最佳实践，模式，标准等。

文章链接有效。即使听起来我想要你的意见，请坚持事实（x因为y和z而更好......）

Answer 1

大多数SOAP客户端会将故障转换为运行时异常（如果这是客户端语言支持的话）。考虑到这一点，我认为您可以将问题改为“我什么时候想抛出异常而不是返回错误值”？我相信你可以找到很多关于API设计的意见，尤其是那个主题。

也就是说，返回错误通常对客户没有帮助：

1. 客户端需要手动枚举和处理错误代码，而不是允许存根代码生成并抛出相应类型的异常。使用错误代码可以防止客户端使用面向对象的技术，例如通过超类处理异常。

2. 如果不将错误代码作为WSDL的一部分;客户将没有关于它们是什么或何时发生的文档。类型化的错误是WSDL的一部分，因此（在某种程度上）自我记录。

3. 故障消息可以包含特定于故障的上下文，客户端可以使用该上下文进行错误报告和恢复。例如，抛出包含实际无效输入元素和原因的输入验证错误。如果您返回带有错误代码和不透明字符串的结果，则客户端别无选择，只能将错误消息传递给用户，这会破坏国际化，UI一致性等。

回答您的具体问题：

1. 验证错误是一个错误。想象一下，如果您从具有有限错误处理能力的AJAX客户端调用Web服务;您希望服务返回5xx HTTP代码，而不是400成功代码以及一些意外响应。

2. 没有。 API应提供一致的错误报告界面。 WSDL设计是API设计。强制客户端实现两个不同的错误处理程序并不会使客户端的生活更轻松。

3. 故障设计应该镜像您的请求/响应模型并显示适合于服务抽象的信息。不要设计NullReference错误;设计一个XYZServiceRuntimeFault。如果客户端经常提供无效请求，请使用适当的子类设计InvalidRequestFault，以便客户端可以快速找出无效数据的位置。

Answer 2

结果对象应该只包含结果。如果您的结果对象提供了另一个系统上发生的错误列表，那么这就是您何时可以拥有“isError”标志的示例;否则你不能因为结果有效或无效。

发生错误时，您应始终使用SOAPFault。验证是一个错误，并且认为验证比无法打开数据库更严重，这是恶魔自己的陷阱。两种情况都具有相同的影响 - 无法按要求完成操作。

因此，您应该将结果对象用于结果，并将SOAP Fault用于阻止有效结果对象的任何事情;包括但不限于错误，验证失败，警告，总线故障等。

在异常之前的日子里没有选择，因此许多API变得不一致，并且大多数API在如何返回错误方面存在差异。它（并且仍然）可怕，令人困惑并且通常会降低开发速度，因为您必须查找每个API条目如何返回错误，以及通常如何解码或查找有关错误的更多信息。

1. 使用SOAPFaults / Exceptions处理验证在您考虑它时更合乎逻辑，一旦您想到它通常会更容易。您确实需要设计验证错误类，以便它包含足够的信息，以不一定需要原始请求的方式识别有问题的元素。这样您就可以开始更一般地处理验证错误。

2. 如果结果对象包含错误，则它们只能在结果的域内;例如产品缺货，因为wharehouse中的某个人无法计算在库存控制范围内。

3. 区分严重错误和验证错误是不明智的，这在我看来并不是一个有效的比较，因为任何严重级别的分配都是非常主观的。例如，在向消防员提供有关化学品的信息的系统中，关键可能意味着着火的卡车正在运载UN 1298＆amp;尝试加载警告图形时，UN 1436而不是空引用。

   设计故障，以便简明地识别故障并进行相应处理。确保它们传达足够的信息。当您获得足够的信息时，由于故障将允许自己被识别，因此无意义的分类是不必要的。

4. SOAPFaults变成异常是最快的失败方式。

5. 最佳做法，参考资料等。

   • Managing Exceptions in a SOA world: Ramesh Ranganathan

   • When Exceptions Are the Rule : Achieving reliable and traceable service-oriented architectures

   • Best practices on SOAP Faults

   • Use SOAP Faults to deliver the appropriate level of detail to the developer at development time, and to the customer while the Web service is in production.

   • Web services use SOAP faults to report fault cases back to clients. The faults can be generated from the SOAP framework in a case of invalid SOAP messages, invalid security tokens or they can be generated from the service business logic itself

   • If you send a message that was not successful for some reason, you may get back a response containing a SOAP fault element, which gives you status information, error information, or both. There can be only one SOAP fault element in a message, and it must be an entry in the SOAP body. Furthermore, if there is a SOAP fault element in the SOAP body, there can be no other elements in the SOAP body. This means that when you add a SOAP fault element, you have effectively completed the construction of the SOAP body.

   • SOAP fault messages are the mechanism by which SOAP applications report errors “upstream,” to nodes earlier in the message path. It's the mission of this section to provide a full and detailed explanation of SOAP faults so that you can handle them appropriately in your own Web services.

Answer 3

我认为简短的回答是使用肥皂故障，除非您知道客户端将配备处理因结果返回的错误。我也在考虑异常和错误结果之间的类比，如其他答案中所述。

根据客户的需要，有灰色区域可以合理地视为异常和结果错误。然后，您可以为服务提供一个参数，以更改返回这些类型的错误的方式。默认情况下使用SOAP错误，但如果客户端设置参数以获取错误结果，则表明它愿意将此作为结果的一部分来处理。对我来说，验证错误就在这个灰色区域。对于大多数客户端，它们应被视为故障，但如果客户端希望使用数据来标记具有验证错误的UI，则将验证错误作为结果的一部分返回可能更有用。

Answer 4

我在服务设计中遵循的规则是：

• 业务级别响应（甚至业务异常）到响应对象
• 技术/集成级别故障进入Soap Fault

服务使用者可以依赖所有类型的业务响应来自响应对象并将其呈现给服务（业务）用户。肥皂故障仅在无法提供业务响应时使用。

肥皂故障应通过监控触发支持警告/行动。