REST and XML using Spring MVC and Groovy

There’s one particular thing Groovy is really good for and that is working with XML. When I started playing around with the REST support in the latest version of Spring MVC I wanted to try using Spring for the controller infrastructure and delegate to Groovy for producing XML responses. It turned out this wasn’t as easy as expected.

The built-in support for rendering XML from RESTful web services in Spring is built on top of the Marshaller abstraction originally from Spring Web Services (now moved to Spring core). This is a pretty nice abstraction if you want to use one of the existing Object-XML marshalling frameworks (JAXB, Castor, XMLBeans, etc.), but if you want to move out of that box you’re pretty much stranded.

I really do want to move out of the box because I think the control and readability greatly improves if you do your XML marshalling in Groovy. It’s quite common that the same domain object will need to be marshalled differently depending on the scenario (an object will e.g. quite probably need to be marshalled differently in a detail view than in a list). Also, it is not uncommon that more complicated application logic will be required when rendering the XML; a common example of this is URI generation in ‘linked’ REST applications (HATEOAS). Hence, Groovy is the perfect choice: Very little code is needed, you are able to include some logic if necessary, and the code written exactly reflects the XML that will be produced.

The Building Blocks

I started out by defining a simple interface for a completely generic Marshaller:

I now needed a View implementation to render Model objects using the SimpleMarshaller interface (much of this code is actually borrowed from the Spring MarshallingView – Apache license rocks!):

Next I created an abstract SimpleMarshaller implementation for marshalling using a Groovy MarkupBuilder:

Now all that is left is to create a new Groovy View implementation for specific XML response you want, e.g.:

Note above that we included some processing logic as well – we get a formatted date and we also make use of a service for producing URIs for referencing sub-entities.

Each individual View implementations now needs to be registered in the DispatcherServlet‘s ApplicationContext:

Since we have defined a BeanNameViewResolver we can now refer to these Views using their bean names when pointing them out from a Controller:

Infrastructure

Obviously, for the above to work we need organize our code appropriately and make sure that our build system properly builds the groovy files. This turned out to be surprisingly easy (using maven). All groovy code should be placed under src/main/groovy. Then maven needs to be configured to build the groovy files using the gmaven plugin. Also, make sure you include the groovy libs in your dependency list:

Conclusion

With the above setup it’s easy to quickly implement (and test) new marshalling views for the different resources in a REST application. Even though this was used in a rather small proof-of-concept project my general feeling is that the approach will work pretty well. My next step with this will be to add some simplifications for working with HTTP status codes (the approach to HTTP response codes with the @ResponseCode annotation in Spring MVC feels insufficient for many cases).

Finally it should be noted that the approach with a completely generic marshaller makes it easy to expand this to working with other representations as well, e.g. JSON (although the JSON support in Groovy is still a little bit shaky).

This Post Has One Comment

  1. some good stuff, thanks!

Leave a Reply

Close Menu