Your opinion on HTTP status codes for webservice faults

I am aware that this question is a little off when it comes to Mendix i hope you can bear with me to read my argumentation and share your thoughts on how to handel webservice responses. When calling a webservice over SOAP with HTTP there are 2 different layers that both can have their own errors. HTTP should handel everything concerning the connection e.g. timeouts (408) bad requests (404) or unauthorized (401). While SOAP the evenlope can contain a SoapFault with a code to describe where it went wrong and a description of what went wrong. This on itself is pretty clear, but there is one HTTP status code that i did not mention above which is the internal server error (500) code. This code can be used for any undefined error that happens on the server, like a SOAP fault. While the SOAP fault itself does not cause for a connection failure or any disruption in your communication it is an error. Thus it would be nice if we could detect this on a higher level. Currently Mendix always responds with a HTTP OK (200) code, even if due to a nullpointer exception an internal server error occurs. This does seem a little unconsistend as they even name the error type the same way. I opt for a system where any SOAP fault results in a HTTP 500 code. Besides it being more consistent this would also allow for cases where you would not have to parse results that contain the HTTP 200 code i.e. if you do nothing with the response message. I would love to hear some other thoughts on this topic.
1 answers

Web Services is about integration, so the most important part here is, what do the standards specify ( What do client applications expect?

As far as i'm aware a SOAP fault is also used to report application level errors? In this case, a 500 HTTP code doesn't seem the appropriate response. For example, if the web service tries to add a new customer, but that customer already exists, the webservice would respond with a SOAP fault indicating that the customer cannot be inserted. This is a normal situation that should not result in a 500 error.

Seems the advise in the second part above is not recommended: The webservices specs aren't explicit enough about this issue, so the best thing is to comply to WS-I basic profile, which gives recommendations for the use of webservices. The 500 status is a difficult issue, the WS-I Basic profile has been changed on this subject between version 1.1 and version 2.0.

Version 1.1: R1126 An INSTANCE MUST return a "500 Internal Server Error" HTTP status code if the response envelope is a Fault.

Version 2.0 removed the explicit recommendation about status code 500, but it does state: R1111 An INSTANCE SHOULD use a "200 OK" HTTP status code on a response message that contains an envelope that is not a fault.

So concluding: status code 500 when returning a fault is conform WS-I basic profile.