It's funny how many developers (myself including) return CreateUserResponse

More seriously - service layer need not to know how it would be accessed (REST, SOAP, something else...), so it should not have any influence on the exception processing in the service layer. It is responsibility of the presentation layer to convert service layer exceptions into something understandable to the clients. In case of the REST it may be appropriate HTTP status code (http://www.iana.org/assignments/http-status-codes) and some text message. For example in case of "business" exceptions we include the message from exception object itself and for all others just server error message along with some id that allows us easily find detailed info in logs.



Quote Originally Posted by sky33 View Post
Sorry, I realize I am late to the game on this one, but I was wondering about a little bit different approach. When you have a service that could possibly be exposed to non-java clients as a SOAP based or REST based web service, is it a good approach to include exception conditions the return type? I think that SOAP uses faults, but what about REST based services? So in the case of createUser(), maybe I am returning a CreateUserResponse object which has the created User on success (+ maybe other contextual data), but also contains the error message(s) on failure. The messages could be broken out into system vs. business errors. I ask the question because I have seen a few public web services take this approach. Any thoughts on that approach?