About Eugen Paraschiv

Testing REST with multiple MIME types

1. Overview

This article will focus on testing a RESTful Service with multiple Media Types/representations. This is the tenth of a series of articles about setting up a secure RESTful Web Service using Spring and Spring Security with Java based configuration.

2. Goals

Any RESTful service needs to expose it’s Resources as representations using some sort of Media Type, and in many cases more than a single one. The client will set the Accept header to choose the type of representation it asks for from the service. Since the Resource can have multiple representations, the server will have to implement a mechanism responsible with choosing the right representation – also known as Content Negotiation. Thus, if the client asks for application/xml, then it should get an XML representation of the Resource, and if it asks for application/json, then it should get JSON.

This article will explain how to write integration tests capable of switching between the multiple types of representations that the RESTful Service supports. The goal is to be able to run the exact same test consuming the exact same URIs of the service, just asking for a different Media Type.

3. Testing Infrastructure

We’ll begin by defining a simple interface for a marshaller – this will be the main abstraction that will allow the test to switch between different Media Types:

public interface IMarshaller {
...
String getMime();
}

Then we need a way to initialize the right marshaller based on some form of external configuration. For this mechanism, we will use a Spring FactoryBean to initialize the marshaller and a simple property to determine which marshaller to use:

Note that these marshallers are not define as Spring components themselved. The reason for that is they will be bootstrapped into the Spring context by the TestMarshallerFactory, so there is no need to make them components directly.

5. Consuming the Service with both JSON and XML

At this point we should be able to run a full integration test against the deployed RESTful service. Using the marshaller is straighforward – an IMarshaller is simply injected directly into the test:

The exact marshaller that will be injected by Spring will of course be decided by the value of test.mime property; this could be picked up from a properties file or simply set on the test environment manually. If however a value is not provided for this property, the TestMarshallerFactory will simply fall back on the default marshaller – the JSON marshaller.

6. Maven and Jenkins

If Maven is set up to run integration tests against an already deployed RESTful Service, then it can be run like this:

mvn test -Dtest.mime=xml

Or, if this the build uses the integration-test phase of the Maven lifecycle:

mvn integration-test -Dtest.mime=xml

For more details about how to use these phases and how to set up the a Maven build so that it will bind the deployment of the application to the pre-integration-test goal, run the integration tests in the integration-test goal and then shut down the deployed service in on post-integration-test, see the Integration Testing with Maven article.

With Jenkins, the job must be configured with:

This build is parameterized

And the String parameter: test.mime=xml added.

A common Jenkins configuration would be having to jobs running the same set of integration tests against the deployed service – one with XML and the other with JSON representations.

7. Conclusion

This article showed how to properly test a REST API. Most APIs do publish their resources under multiple representations, so testing all of these representations is vital, and using the exact same tests for that is just cool.

For a full implementation of this mecahnism in actual integration tests verifying both the XML and JSON representations of all Resources, check out the github project.

Join Us

With 1,240,600 monthly unique visitors and over 500 authors we are placed among the top Java related sites around. Constantly being on the lookout for partners; we encourage you to join us. So If you have a blog with unique and interesting content then you should check out our JCG partners program. You can also be a guest writer for Java Code Geeks and hone your writing skills!

Disclaimer

All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners. Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries. Examples Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.