Java-based configuration in Spring - An introduction

If you have not started using Java-based configuration in your Spring projects you really should take a look at it since it is a very valuable tool to master. Java-based configuration has been supported right out of the box since Spring 3.0 so it has become quite complete by now. (with the stable release being 3.2.x at the time of writing this post)
Personally, I have found that I hardly ever use any XML configuration files in Spring projects that I create nowadays. And as a side note, if I am also able to use an application server that supports Servlet 3.0 I can even get rid of my web.xml file. Thus eliminating a big part of the XML-based configuration usually needed.

Ok, but why? You might ask. Well, if you think about it there are a lot of benefits of having your configuration in code instead of in XML.

Controlling message converters with Spring MVC 3.1

In my previous post I talked about how to support both JSON and XML in a Spring MVC web service. The observant reader might have noticed that if a request was made with an Accept header with neither application/json nor application/xml specified then the data was returned in XML. The integration test in the example code used to illustrate this looked like this:

@Test
 public void getUserWithUnsupportedAccept() throws Exception {
  RestTemplate restTemplate = createStringRestTemplate();

  String user = restTemplate.getForObject(new URI(baseUrl + "/123"), String.class);

  logger.debug("Received data as: {}", user);
 }

The code will log the received data and you can see that it is in XML format. The reason for this is how the message converters are added by default. Go check out the Spring source code if you want to know the details.

Now, if you rather want JSON to be the default format then changing the behavior of our web service is simply a matter of defining our own order for the message converters and make sure the JSON converter comes before the Jaxb converter.

Combining JSON and XML in RESTful web services with Spring MVC

There are occasions when you need to support multiple representations of the same resource in a REST API. For example, a smartphone client might want the resource to be represented in JSON while your B2B partner's application that is integrating through your API wants the representation to be XML.

Willie Wheeler wrote an excellent blog post about how to support both XML and JSON from a web service endpoint using the new features of the @RequestMapping annotation in Spring 3.1. The example in the blog post, by intention, uses two different URLs for the two different representations.

However, when dealing with RESTful services the preferred approach to design your API would usually be to have a single URL for the resource regardless of what representation the requesting client is asking for. A way to solve this is to let the requesting client specify what representation it prefers via the Accept header in the HTTP request. The server will examine the request header and send back the resource in the proper representation. This can very easily be implemented by using Spring MVC and I figured I will show you how this can be accomplished with the following example.