SOAP错误或结果对象？

Question

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

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

有些要考虑的要点:

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

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

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和UN 1436而不是空参考.

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

4. SOAPFaults变成Exceptions是最快速的失败方式.

5. 最佳实践,参考文献等

   • 管理SOA世界中的异常:Ramesh Ranganathan

   • 当例外是规则时:实现可靠且可追溯的面向服务的体系结构

   • SOAP错误的最佳实践

   • 使用SOAP Faults在开发时向开发人员提供适当级别的详细信息,并在Web服务生产时为客户提供.

   • Web服务使用SOAP故障将故障情况报告回客户端.在无效的SOAP消息,无效的安全令牌或者可以从服务业务逻辑本身生成故障的情况下,可以从SOAP框架生成故障

   • 如果由于某种原因发送了一条未成功的消息,您可能会收到包含SOAP fault元素的响应,该元素会为您提供状态信息,错误信息或两者.消息中只能有一个SOAP fault元素,它必须是SOAP正文中的一个条目.此外,如果SOAP主体中存在SOAP fault元素,则SOAP主体中不能有其他元素.这意味着当您添加SOAP fault元素时,您已经有效地完成了SOAP主体的构造.

   • SOAP错误消息是SOAP应用程序向消息路径中较早的节点"上游"报告错误的机制.本节的任务是提供SOAP故障的完整详细说明,以便您可以在自己的Web服务中正确处理它们.

Answer 3

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

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