Monthly Archives: April 2015

Build a RESTful stub server with Dropwizard

Last Updated on by

Post summary: How to make RESTful server that can be used for stub during testing.

It might happen that you are testing a REST client against server that is not under your control. It might happen that server is not in your network, server is not very stable, has sensitive data, has changing and unstable data, etc. In such cases it might be hard to do proper automation testing. Solution to such situation is a server stub that responds to REST request in a predictable manner. This is tutorial how to do it.


Dropwizard is Java framework for building RESTful web server in very short time. It has incorporated proven libraries like Jetty, Jersey, Jackson and many more to reliably do the job in shortest possible time. They have very good getting started tutorial how to make a project from scratch. I’ve used it to create project on my own. Steps are described bellow.

How to do it

  1. Create Maven project
  2. Add Dropwizard dependency
  3. Build with Maven
  4. Add configuration file
  5. Add configuration class
  6. Add data classes
  7. Add service classes
  8. Add health check
  9. Add Dropwizard application
  10. Build everything into a single JAR file
  11. Run it
  12. Test and enjoy

Create Maven project

Maven is central build repository for JARs. It makes it very easy to manage dependencies between libraries. Before getting started with Maven it should be installed. Once you do this path to Maven bin folder should be added in your Path environment variable (Windows). Once you do this open command prompt an type “mvn –version” to test if everything is configured correctly. If OK then make project with command bellow. Important in command is “groupId” this is Java package and “artifactId” this is project name:

mvn -B archetype:generate

Project can be created directly from IntelliJ, but I would recommend to create it with maven to get acknowledged to it.

Build with Gradle

How to build same project with Gradle instead of Maven can be found in Build a Dropwizard project with Gradle post.

Add Dropwizard dependency

Run your favorite IDE and import already created Maven project. In this tutorial I’ll use IntelliJ. From project structure open pom.xml file. If project was created with Maven there should be <dependencies> section with junit in it. You can remove junit and add following XML instead.


Build with Maven

Since you have created project with Maven you have it configured and know how to use it. Navigate to projects folder and run “mvn package” command. When run first time it takes a while since all dependencies are being loaded to local Maven repository.

Once build is done go to IntelliJ and refresh Maven JARs. Right click on project -> Maven (in the bottom) -> Reimport.

Add configuration file

Configurations in Dropwizard are managed with YAML. In short key value pairs are separated with colon. Child elements are indented with two spaces from their parent. Repeating items are shown with dash in front. Configuration file is with *.yml extension. Add “config.yml” file in IntelliJ project. Bellow is use configuration we are about to use in this tutorial. “version” is our custom property to illustrate working with configurations. “server” is standard Dropwizard property. With those part we set application listen port to 9000 and administration port to 9001. With “-type” is shown repetitive sequence. In current situation it is http, but there may be several protocols provided. “port” is its child key/value pair.

version: 0.0.1

# Change default server ports
  - type: http
    port: 9000
  - type: http
    port: 9001

Add configuration class

Once we have configuration file we need a class that will handle it. As I said “version” is our custom configuration property. In order to handle it our class should extend Configuration. Define field with getter and setter. Annotate getter and setter with @JsonProperty and you are ready to go. If more properties are needed more fields with getters and setters should be defined in class.

package com.automationrhapsody.reststub;

import com.fasterxml.jackson.annotation.JsonProperty;
import io.dropwizard.Configuration;
import org.hibernate.validator.constraints.NotEmpty;

public class RestStubConfig extends Configuration {
	private String version;

	public String getVersion() {
		return version;

	public void setVersion(String version) {
		this.version = version;

Create data classes

Term in Dropwizard for those POJOs is “Representation Class” but in general ther are objects to exchange data. In our example we have Person class which has very basic attributes. It has only getters in order to be immutable. Getters are annotated with @JsonProperty  which allows Jackson to serialize and deserialize from JSON. Note that there is empty constructor which is needed for Jackson’s deserialization.


import com.fasterxml.jackson.annotation.JsonProperty;

public class Person {
	private int id;
	private String firstName;
	private String lastName;
	private String email;

	public Person() {
		// Needed by Jackson deserialization

	public Person(int id, String firstName, String lastName, String email) { = id;
		this.firstName = firstName;
		this.lastName = lastName; = email;

	public int getId() {
		return id;

	public String getFirstName() {
		return firstName;

	public String getLastName() {
		return lastName;

	public String getEmail() {
		return email;

If data to be exchanged gets too much data classes will become enormous. One solution to reduce their size is to use Lombok. See how it is done in Get rid of Getters and Setters post.

Create service

Term in Dropwizard is “Resource Class” but this actually is the RESTful service with its endpoints. @Path provides where the endpoint is. In current example I have “/person” for whole class and different paths for different operations. The result is that paths are concatenated. @GET and @POST indicate type of the request. @Timed is put for analytics purposes. @Produces and @Consumes provide type of data that is being exchanged. @PathParam indicates that “id” is part of the URL.

package com.automationrhapsody.reststub.resources;

import com.automationrhapsody.reststub.persistence.PersonDB;
import com.codahale.metrics.annotation.Timed;

import java.util.List;

public class PersonService {

	public PersonService() {

	public Person getPerson(@PathParam("id") int id) {
		return PersonDB.getById(id);

	public String removePerson() {
		return "Last person remove. Total count: " + PersonDB.getCount();

	public List<Person> getPersons() {
		return PersonDB.getAll();

	public String addPerson(Person person) {

Service operations

Example above is about RESTful service dealing with person data. There are 4 operations exposed on following URLs:

  • /person/get/{id} – by provided person unique “id” it returns JSON with person data
  • /person/remove – removes one person on random basis
  • /person/all – returns JSON with all persons data
  • /person/save – receives JSON with person data and saves it to persons if “id” is unique, if not updating person by its id.

Business logic

It is little overrated to call it business logic but this is how we manage persons. If this was a production application you might have lots of business logic and some DB (SQL or no-SQL). Since this is just a test stub it is enough to have some data structure where to keep persons. In our case HashMap is selected. There are static methods manipulating data.

package com.automationrhapsody.reststub.persistence;


import java.util.ArrayList;
import java.util.HashMap;
import java.util.List;
import java.util.Map;

public class PersonDB {
	private static Map<Integer, Person> persons = new HashMap<Integer, Person>();

	static {
		persons.put(1, new Person(1, "FN1", "LN1", ""));
		persons.put(2, new Person(2, "FN2", "LN2", ""));
		persons.put(3, new Person(3, "FN3", "LN3", ""));
		persons.put(4, new Person(4, "FN4", "LN4", ""));

	public static Person getById(int id) {
		return persons.get(id);

	public static List<Person> getAll() {
		List<Person> result = new ArrayList<Person>();
		for (Integer key : persons.keySet()) {
		return result;

	public static int getCount() {
		return persons.size();

	public static void remove() {
		if (!persons.keySet().isEmpty()) {

	public static String save(Person person) {
		String result = "";
		if (persons.get(person.getId()) != null) {
			result = "Updated Person with id=" + person.getId();
		} else {
			result = "Added Person with id=" + person.getId();
		persons.put(person.getId(), person);
		return result;

Create health check

Health check is smoke test that can be called from admin panel to give you information about the status of the system. In production systems you might do things like checking DB connection, checking file system or network, checking important functionality. In example here just to illustrate the functionality my health check is count of persons in memory. If it goes to 0 then something is wrong and system is not healthy. Also to illustrate how properties are used “version” is passed from configuration file to health check via its constructor.

package com.automationrhapsody.reststub;

import com.automationrhapsody.reststub.persistence.PersonDB;

public class RestStubCheck extends HealthCheck {
	private final String version;

	public RestStubCheck(String version) {
		this.version = version;

	protected Result check() throws Exception {
		if (PersonDB.getCount() == 0) {
			return Result.unhealthy("No persons in DB! Version: " +
		return Result.healthy("OK with version: " + this.version +
				". Persons count: " + PersonDB.getCount());

Create application

This is the final piece. Once we have all (data, service, health check) application is binding piece that brings them together. This is execution entry point. In “main” method new application is created and its run() method is called. This is it. In order to actually work service and health check should be registered. This is done in the run method. You create instance of both service and health check. Configuration is passed in health check’s constructor.

package com.automationrhapsody.reststub;

import com.automationrhapsody.reststub.resources.BookService;
import com.automationrhapsody.reststub.resources.PersonService;
import io.dropwizard.Application;
import io.dropwizard.setup.Environment;

public class RestStubApp extends Application<RestStubConfig> {

	public static void main(String[] args) throws Exception {
		new RestStubApp().run(args);

	public void run(RestStubConfig config, Environment env) {
		final PersonService personService = new PersonService();

			new RestStubCheck(config.getVersion()));

Build a single JAR

This was it now all have to be packed into a JAR. The strategy is to build everything into one JAR and just run it. It could not be more simple. Open pom.xml file. Add <build><plugins> … </plugins></build> in the end. Add XML bellow into this snippet. Only <mainClass> is customisable and should be changed according to your project structure.

					<transformer implementation="org.apache.maven.plugins.shade.resource.ServicesResourceTransformer"/>
					<transformer implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">

Build and run

Once this is done use “mvn package” to make the JAR. Navigate to target folder in your project and run the JAR. Two arguments are needed in order to run the JAR. First is “server” which instructs Dropwizard to run as server. Second is path to *.yml configuration file.

java -jar sample-dropwizard-rest-stub-1.0-SNAPSHOT.jar server ../config.yml

If everything is fine you should see something like code bellow which will mean server is ready.

GET     /person/all (...)
GET     /person/get/{id} (...)
GET     /person/remove (...)
POST    /person/save (...)

Test and enjoy

Once all this hard work has been done it is time to enjoy our RESTful server. List with all persons can be found on this URL: http://localhost:9000/person/all. You can get person by id: http://localhost:9000/person/get/1.

Health checks are found in admin panel: http://localhost:9001. Try removing all persons by invoking several times this URL: http://localhost:9000/person/remove

And the hardest part is to save a person. I’m using Postman Chrome plugin but you can use any REST client you want. You have to put POST data against http://localhost:9000/person/remove URL.


And most important DO not forget to put “Content-Type: application/json” in request header. If you do not put you will get “Error 415 Unsupported Media Type” error.


Sample application can be found in GitHub sample-dropwizard-rest-stub repository. Postman requests can be downloaded from Dropwizard Postman requests link and directly imported into Postman.

Another way to test the stub is by building a client as described in Create simple REST API client using Jersey post.

Run with Docker

In Run Dropwizard application in Docker with templated configuration using environment variables post I have described how to make Dropwizard application configuration be changed with environment variables which makes it very easy to build and run in inside Docker container.


It could not be more easier. If you really need to stub a RESTful server this is the proper way to do it.


Get rid of Getters and Setters

Last Updated on by

Post summary: Use Project Lombok to reduce amount of code you have to write by automating Getters and Setters generation

C# has Properties, special methods which look like public data members but behind the scenes are special methods. This allows data to be accessed easily and less code to be written.


Properties behavior in Java is implemented with so called Getters and Setters which generally are normal methods with special name. Encapsulation is important OOP principle that requires data fields to be hidden for outside world. Even in test code it is not good to break this principle. So we need to write lots of Getters and Setters to expose data fields. Even that all IDEs provide a way to generate them automatically worst thing is that class is polluted with lots of methods that are actually insignificant.

Get rid of Getters and Setters

Project Lombok is a solution for having less code in your classes. You do not need to worry about writing Getters and Setters anymore. They are automatically added at compile time. What you need to to is just annotate your class or fields. One option is to directly put @Data annotation on class level. Other option is to put restrictions on each field if you are too picky.


In some cases there is some processing of values Getter or Setter. This is not a problem you can implement only this method. If Lombok sees there is Getter or Setter it is ignoring it at compile time. In example bellow correct getIsbn() is being used.

import lombok.Data;

public class Book {
	private String isbn;
	private String name;
	private String author;

	public Book(String isbn, String name, String author) {
		this.isbn = isbn; = name; = author;

	public String getIsbn() {
		return "ISBN: " + isbn;


Although getters and setters are generated only once code is more readable without them. UPDATE: After having some real usage of project Lombok I would recommended not to use it. There are situations where debugging is not possible, also code navigation through IDE is hard.