REST-Assured 3.0

I started using REST-Assured framework around version 1.5 and since then it’s my first-choice REST client for test automation projects. Back then it was very straight forward, but still way better than it’s available, verbose equivalents. It’s major pros are ease of use – you basically add one static import and you’re ready to go, and BDD convention, which improves readability a lot. But when you dive deeper into REST-Assured framework, you’ll find many handy features, like object serialization, built-in assertions, response manipulation, etc. I already write two post about REST-Assured (framework overview, and more advanced), which become two most popular articles on my blog. Since then the framework gained a lot of popularity and it’s still being developed.

We have version 3.x now, with some great announcements. If you don’t want to study release notes (which I highly recommend!), take a look at this post, with overview of the major changes and new features.


First of all, 3.0.0 version introduces new group-id. If you’re a Maven user, you need to change your dependency as follows:


…and If you’re on the light side of the force – dependency for Gradle:

testCompile group: '', name: 'rest-assured', version: restassured.version

Of course, If you want to follow this convention you need to define restassured.version as a variable.

JsonPath object serialization

In most projects, domain model is a vast part of the code base. In automated acceptance tests usually we need rather small portion of model or just simple domain-transfer objects. REST-Assured makes creating models easier by partial response serialization (example below comes from official documentation).

Let’s assume you have a following response:

But you don’t want to handle whole store object for your tests, you just want to have a list of book objects. With use of JsonPath, you serialize extracted list:

List<Book> books = JsonPath.from(json).getList("", Book.class);

Validating response time

Latency is a huge factor in the world of distributed systems and microservices. Since in REST architecture we use HTTP calls, response time is yet another value to measure. In REST-Assured 3.x (it was originally introduced in version 2.8) you can not only measure HTTP response times:

long responseTime = get("").time()

…but also make assertions based on response time:


Injecting request method

Announced with 3.0 release, REST-Assured offers now a possibility to inject HTTP method as a request() method parameter. This feature adds tons of flexibility to your test development: you can use custom methods, conditional-pass request methods or just parametrize test cases. Below you can check example of a data-driven test case parametrized with HTTP method and expected response (test runner is spock):

With use of request() method and some spock magic, We have several test-cases (see @Unroll annotation) with no code-repetition:


Continue reading

If you want to continue reading and expand your knowledge in area of  REST and microservices, I recommend you these books:

  • Building Microservices – one of the most important books for me, everything you want to know about microservices is here
  • RESTful Web APIs – another great book about REST architecture. Lots of practical knowledge about designing and consuming RESTful APIs


For those who’re looking for REST client for automated tests, give a try to REST-Assured. With 3.0 release and it’s new features it’s very flexible yet powerful tool.

If you have any questions for given examples or just want to share your thoughts – feel free to leave a comment.