SOAP错误或结果对象？ [英] SOAP faults or results object?

问题描述

我正在与同事进行讨论，我们不能达成协议，所以我想得到你的想法。我有自己的意见，但是我不会为你折服。

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

有些要考虑的点：

1. 数据验证错误是否为错误？


2. 如果存在组合故障（非常特殊情况）和结果对象（对于预期错误）？


3. 如何分组SOAP错误（关键[null reference] vs验证[邮政编码不正确]）？


4. 失败快速与必须记住检查错误


5. 最佳做法，模式，标准等。

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

解决方案

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

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

1. 客户端需要手动枚举和处理错误代码，同时允许存根代码生成并抛出异常适当的类型。使用错误代码阻止客户端使用面向对象的技术，例如处理超类的异常。




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




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

回答您的具体问题：

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




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




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

I was having a discussion about this with a co-worker and we couldn't come to an agreement, so I wanted to get your thoughts. I have my own opinions on this, but I won't spoil it for you.

When should I be returning a SOAP fault and when should I be returning a result object that has error information? Assume this is for a generic web service that can be consumed by various systems (.NET, Java, whatever). The result object would have an isError flag, an errorType (similar to specific exception type), and a message.

Some points to consider:

1. Is a data validation error a fault?
2. Should there be a combination of faults (for very exceptional cases) and the results object (for "expected" errors)?
3. How would you group SOAP faults (critical [null reference] vs validation [zip code incorrect])?
4. Fail-fast vs having to remember to check for error
5. Best practices, patterns, standards, etc.

Links to articles are valid. Even though it sounds like I want your opinion, please stick to facts (x is better because of y and z...)

解决方案

Most SOAP clients will convert faults into a runtime exception (if that is something the client language supports). With that in mind, I think you could rephrase the question as "When do I want to throw an exception instead of returning an error value"? I'm sure you can find lots of opinions about that API design in general and that topic in particular.

That said, returning an error is usually not helpful to the client:

1. The client needs to manually enumerate and handle your error codes vs. allowing the stub code to generate and throw an exception of the appropriate type. Using error codes prevents the client from using object-oriented techniques like handling exceptions by superclass.

2. If you don't make your error codes part of the WSDL; the client will have no documentation on what they are or when they occur. Typed faults are part of the WSDL and therefore (to some limited extent) self-documenting.

3. Fault messages can contain fault-specific context that the client can make use of for error reporting and recovery. For example, throwing an input validation fault containing the actual invalid input element and a reason. If you return a result with an error code and an opaque string, the client has little choice but to pass your error message on to the user, which breaks internationalization, UI consistency, etc.

To answer your specific questions:

1. A validation error is a fault. Imagine if you invoke the web service from an AJAX client with limited error handling ability; you want the service to return a 5xx HTTP code, not a 400 success code with some unexpected response.

2. No. APIs should provide consistent error reporting interfaces. WSDL design is API design. Forcing the client to implement two distinct error handlers does not make the client's life easier.

3. Fault design should mirror your request/response model and display information appropriate to the abstraction of the service. Don't design a NullReference fault; design a XYZServiceRuntimeFault. If clients frequently provide invalid requests, design a InvalidRequestFault, with appropriate subclasses so that clients can quickly figure out where the invalid data is.

这篇关于SOAP错误或结果对象？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！