Response Specification Explained in REST Assured

When writing API tests with REST Assured, you often need to validate the same response conditions across multiple test cases. Instead of repeating status code, content type, header, or response-time validations in every test, you can use a Response Specification.A response specification helps make REST Assured tests cleaner, reusable, and easier to maintain.

What Is a Response Specification?

A Response Specification in REST Assured is a reusable set of expectations that defines how an API response should look.

For example, suppose every API in your application should return:

• HTTP status code 200
• Content type application/json
• Response time below 2 seconds

Instead of writing these validations repeatedly, you can define them once using ResponseSpecBuilder.

ResponseSpecification responseSpec = new ResponseSpecBuilder()
        .expectStatusCode(200)
        .expectContentType(ContentType.JSON)
        .expectResponseTime(lessThan(2000L))
        .build();

You can then reuse this specification in multiple API tests.

How to Use a Response Specification

Once the response specification is created, use it with the spec() method.

given()
    .when()
    .get("/users")
    .then()
    .spec(responseSpec);

REST Assured will automatically validate the response against all expectations defined in responseSpec.

If the response does not meet any expectation, the test fails.

Why Use Response Specifications?

The biggest advantage of a response specification is reusability.

Without a response specification, you might write:

given()
    .when()
    .get("/users")
    .then()
    .statusCode(200)
    .contentType(ContentType.JSON)
    .time(lessThan(2000L));

You would then repeat the same validations for /products, /orders, /customers, and other endpoints.

With a response specification:

given()
    .when()
    .get("/users")
    .then()
    .spec(responseSpec);

Your test becomes shorter and the common validations are maintained in one place.

Adding More Validations

A response specification can contain many different expectations.

For example:

ResponseSpecification responseSpec = new ResponseSpecBuilder()
        .expectStatusCode(200)
        .expectContentType(ContentType.JSON)
        .expectHeader("Connection", "keep-alive")
        .expectResponseTime(lessThan(2000L))
        .build();

You can also define response body expectations when appropriate:

ResponseSpecification responseSpec = new ResponseSpecBuilder()
        .expectStatusCode(200)
        .expectBody("status", equalTo("success"))
        .build();

This allows you to centralize common API response validations.

Response Specification vs Request Specification

REST Assured also provides RequestSpecification, which is useful for defining common request details such as:

• Base URI
• Authentication
• Headers
• Request content type
• Query parameters

A simple distinction is:

RequestSpecification → How the request should be sent

ResponseSpecification → What the response should contain

For larger automation frameworks, using both can significantly reduce duplicate code.

Best Practice

Keep common validations in a shared response specification and use endpoint-specific assertions inside individual tests.

For example:

given()
    .when()
    .get("/users")
    .then()
    .spec(responseSpec)
    .body("data.size()", greaterThan(0));

Here, responseSpec handles common response validations, while the test performs its specific business validation.

Conclusion

Response Specification in REST Assured is a simple but powerful way to improve API test automation. It allows you to define reusable response expectations for status codes, content types, headers, response times, and other validations.

If your REST Assured framework contains many API tests with repeated response validations, introducing ResponseSpecification can make your test code cleaner, more consistent, and easier to maintain.

Related Articles

• What is API Testing
• REST HTTP Methods
• What is REST Assured
• Setup
• First Test
• Request Specification Explained
• E2E API Testing Flow
• Response Validation
• Authentication methods
• API framework design
• CI/CD Integration for REST Assured