Question

I have a RESTful web service that responds to /user/{userId} with a marshalled XML representation of a User domain object (using JAXB). What’s an appropriate way of communicating back to the client additional details about their request, particularly if it doesn’t return the information they’re expecting? In a non-distributed Java application, you might have a catch block that deals with data access, or security exceptions. In the event that /user/{userId} doesn’t return anything (e.g. the web services persistence mechanism isn’t working, there is a security restriction, etc…) how do I include meaningful information in the response to the client?

I don’t think DTOs are what I need because I’m not looking for different representations of a domain object. Rather, I’m looking for information about what happened during the request that may have prevented it from returning the information the client expected. Would it be appropriate to enclose the domain object within some kind of ResponseObject that holds the relevant metadata? The downside to this approach is that I’d rather not have my service layer interfaces all have ResponseObject as their return type because I may very well provide a non-RESTful implementation that doesn’t have the same metadata requirements.

Answer 1

What’s an appropriate way of communicating back to the client additional details about their request, particularly if it doesn’t return the information they’re expecting.

In the event that /user/{userId} doesn’t return anything (e.g. the web services persistence mechanism isn’t working, there is a security restriction, etc…) how do I include meaningful information in the response to the client?

This is what the HTTP Status Code is used for in a RESTful service.

To indicate that a requested userId doesn’t correspond to an actual user, you can return a 404 Not Found.

To indicate an internal error within your application (such as not being able to connect to the database), you can return 500 Internal Server Error.

The option you are describing – wrapping your returns in a ResponseObject which then includes the true "response status" – sounds an awful lot like SOAP.

The beauty of REST, or at least what people claim, is that you can use the already-existing HTTP response status code to model almost all statuses of your actual response.