Summary of Question:
When is it best to return a fault vs returning a status element as
part of the response? If you believe faults should only be returned
on system-level exceptions, then what if a required element in the
response is inapplicable because of an application-level exception?
How do you resolve that?
Details of Question:
It seems to be a popular opinion that faults should be reserved for
system exceptions (that is, unexpected errors) and status elements
should be used for application exceptions (those errors that are
expected to occur in regular business interactions). While I agree
that this seems a good idea, I've run into one problem. Here is an
example:
Suppose I have an operation called GetTodaysRedSoxScore. The response
XSD might look like this:
<xsd:complexType name="GetTodaysRedSoxScoreResponseType">
<xsd:sequence>
<xsd:element name="Status" type="tns:StatusType" />
<xsd:element name="Opponent" type="xsd:string" />
<xsd:element name="SoxScore" type="xsd:int" />
<xsd:element name="OpponentScore" type="xsd:int" />
</xsd:sequence>
</xsd:complexType>
Now suppose that someone invokes this operation on the Red Sox's day
off. Since this is really an application-level exception, many would
say we should return a status indicating "NO_GAME_SCHEDULED" or
something like that (instead of using a fault). BUTÂ… Opponent,
SoxScore, and OpponentScore are all required elementsÂ… What do I do?
(1) Exclude these elements from my response (thus returning XML that
is not valid against my own schema)?
(2) Return default values for the required elements (empty string for
string, 0 or -1 for int, etc)?
(3) Change the XSD to make all elements nillable?
(4) Change the XSD to make all elements minOccurs="0"?
I don't really like any of these options, so I'm tempted to use a
fault, even though it's not a system level exception.
What is the best practice concerning when it it appropriate to use
faults vs. returning status elements?
-Chris
