Sep 9th, 2009, 05:27 AM
Exception Handling with REST and Content Negotiation, best practice?
In my application, I am making use of Spring's REST support and using a ContentNegotiatingViewResolver so that I can serve different views depending on file-extension and / or Accept Headers whilst keeping the same resource pattern and Controller methods.
What is the best way to handle Exceptions that propagate to the Controllers? The default way with ROO is to use a SimpleMappingExceptionResolver and map Exceptions to JSP view names. This means that if the request is asking for XML, there will be the full Exception Object serialized as XML in the view; not always suitable, a bit too verbose for external consumption.
Would the better way for REST be to do away with the SimpleMappingExceptionResolver and use a @ExceptionHandler annotation in the Controller code and then using a Custom Error Class for a 'nicer' XML view (for example, controlling the XStream Serialization with Annotations if you are using XStream as the Marshaller), or is there a better way to configure the ExceptionResolver bean?
I imagine this is a common scenario for ROO applications because I am sure a lot of people will be building RESTFul apps with it.
Anyone have any advice on this?
all the best
Sep 25th, 2009, 08:20 PM
Your question is interesting .
The ContentNegotiatingViewResolver approach was designed so that the Spring MVC controller is ideally not aware of the content type being rendered. However, since you want to handle the exception rendering depending on the content types I guess the best approach is for you to come up with some custom exception handling.
We have been playing around a little with XML and JSON rendering recently but have not committed any add-on for it as both XStream and Jackson handled mappings require some customization to fit well into Roo applications.
Tags for this Thread