web-services - SOAP 错误或结果对象？

Question

我正在与一位同事讨论此事，但我们无法达成一致，所以我想了解您的想法。我对此有自己的看法，但我不会剧透。

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

需要考虑的一些要点:

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

文章链接有效。尽管听起来我想听听您的意见，请坚持事实(x 更好，因为 y 和 z...)

Answer 1

大多数 SOAP 客户端会将错误转换为运行时异常(如果客户端语言支持的话)。考虑到这一点，我认为您可以将问题改写为“我什么时候想抛出异常而不是返回错误值”？我相信您可以找到很多关于该 API 设计的一般观点，特别是该主题的观点。

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

1. 客户端需要手动枚举和处理错误代码，而不是允许 stub 代码生成并引发适当类型的异常。使用错误代码可以防止客户端使用面向对象的技术，例如通过父类(super class)处理异常。

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

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

回答您的具体问题:

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

2. 没有。 API 应提供一致的错误报告接口(interface)。 WSDL设计就是API设计。强制客户端实现两个不同的错误处理程序并不会让客户端的生活变得更轻松。

3. 故障设计应反射(reflect)您的请求/响应模型并显示适合服务抽象的信息。不要设计NullReference错误；设计 XYZServiceRuntimeFault。如果客户端经常提供无效请求，请设计一个InvalidRequestFault，并带有适当的子类，以便客户端可以快速找出无效数据在哪里。