That makes sense. I looked at some REST examples and did see how you can return an HTTP status code and in addition return the actual error message in the body.
I re-read this thread and ended up with a couple more questions based on find/query type methods of services.
1) Is it advisable to throw some kind of a NotFoundException when you are querying for a single object? Returning null (although I have done it a ton) does not feel right.
2) When returning a list, it has been my practice to return an empty list for something like the following when no users are found:
User getUser(String id)
3) When doing batch style requests, how do I signal a not found condition?
List<User> getUsersWithFirstName(String firstName)
If I don't want to fail the entire call on one bad user id, should I communciate it in some kind of UserResult or UserResponse object that has the User (or not) and some kind of status/error message?
List<UserResult> getUsers(String ids)
What do you think?
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.