Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Handling Multiple Service Responses
 Hi,
I am seeking some opinions about how others handle this situation :-
A service exposes an operation (lets assume it is implemented as a web service using SOAP).
A request is sent to the service and the service may respond with :-
a. A payload representing the expected successful outcome to the request
b. One of a NUMBER of unsuccessful response types (note: I am not necessarily saying these are errors per se)
c. A SOAP Fault indicating some sort of technical failure in calling the service
It is (b) that I am uncertain about.
(i) I want to make it easy for the calling client to discern whether they have a success response, or a non success repsonse (the technical error is easy).
(ii) The calling client may need to take different actions based on which one of the many different UNsuccessful response messages is returned.
For (i) I thought that, rather than returning a different message structure for each different response type (b) I would model this as a common 'business response' structure which [say] includes a business response code that the caller can use to identify which of the 'published' non success outcomes has actually occurred (I am assuming here that these type of responses don't include any useful data other than the response code that the client needs).
This would have the advantage that the client only needs to understand 3 types of response for this operation, the success response, the non success response and the SOAP Fault (rather than 'n' non-success responses)
I considered just using 2 response types, success and SOAP Fault, but I think it might be better to reserve SOAP Faults to non business messages that we don't really want a caller to have to be concerned with (other than the fact that the invocation failed).
I have to say I'm pretty uncertain about this... on the one hand I feel like creating specific message types for all possible responses that the service *could* return, but on the other, this seems like it might just make life more difficult for the caller ?? The determination of what is a business 'error' *may* be in the context of the caller even where the service asserts an error (
i.e. the caller may choose to consume and continue).
Has anyone else faced this predicament or do you have a view about the 'straw man' approach outlined above or a better alternative ?
Cheers
Fraser.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
