views:

897

answers:

4

We are developing a new web service and are looking into the "best practice" for returning errors in the soap response.

We were looking into creating a error response object which every response would contain as a property. This seems a little heavy however and are wondering if it is possible to use the SOAP header to carry this information? How do you normally deal with custom errors using SOAP?

+2  A: 

Soap already uses custom headers for error info, all you need to do is throw an exception on the server side, and exception is raised on the client side as a SoapException.

You can thrown SoapExceptions on the serverside if you want more control over the exception message/info.

Edit: For extra information along with the request, custom soap headers can be used. Here's an example article on CodeProject that used custom soap headers for authentication, but custom soap headers can be used for other purposes like sending extra info that is not necessarily an error condition (can be business logic info)

Pop Catalin
Sorry I'm not sure my question was that clear, I am taking about communicating business rule error in the response. Is it not bad practice to throw exceptions if you can avoid it?
Sheff
You can also add custom soap headers to a response or request for extra info along with the request http://msdn.microsoft.com/en-us/library/system.web.services.protocols.soapheader.aspx
Pop Catalin
+1  A: 

SOAPFault is used to hold error and status information, and server returns 500 in the HTTP header for it to state it as fault.

see the specification from W3.org

http://www.w3.org/TR/2000/NOTE-SOAP-20000508/#_Toc478383507

You can design your own information token by either placing it into soap header or even within an element in your return result as long as you document it clearly for third party. However that is not the standard way to go for raising errors.

codemeit
This looks like the sort of thing we are after. Would you recommend this over a custom error object returned in the response?
Sheff
Customer header solution seems to be working well for you if you document it clearly by saying something like the extra information can be found in soap header. I have done something similar to this.
codemeit
A: 

I've used similar techniques in the past for complex operations. Especially when you need (multiple?) error descriptions as well as as error code.

Matt Lacey
A: 

Soap headers are for out-of-band information, and should not be used for error messages. Furthermore, soap headers should not be used in soap responses because:

  • if mustUnderstand is missing or 0, the client can safely ignore them.
  • if mustUnderstand is 1, the client cannot signal it doesn't understand it (since it's a response).

And yes, I know some WS-* standards describe soap headers in the response...

So,

Use soap faults for errors that are severe enough that there is no response object. Add a status token to the response for warnings and information messages.