REST Assured Visualizer

Given / When / Then

REST Assured reads like a sentence. given() sets up the request — headers, query and path params, body, authentication. when() fires the HTTP method (get, post, put, delete). then() asserts on the response: status code, headers and body. This BDD-style chaining keeps API tests short and readable even for people who did not write them.

Request and response specifications

RequestSpecification and ResponseSpecification let you define common setup once — a base URI, default headers, an auth token, an expected content type — and reuse it across an entire suite. This is the single biggest maintainability win in a large REST Assured project, because a change to the base URL or auth scheme happens in one place.

Assertions with JsonPath and Hamcrest

You validate responses with Hamcrest matchers. Pull values out of the JSON body with a GPath/JsonPath expression: body("user.id", equalTo(1)), body("data.size()", greaterThan(0)). For contract testing, validate the whole payload against a JSON schema with matchesJsonSchemaInClasspath("user-schema.json").

Serialization and POJOs

Rather than hand-building JSON strings, REST Assured can serialize a Java object (POJO) into the request body and deserialize the response back into a POJO with .as(User.class). This gives you type-safe, refactor-friendly API tests and is a common follow-up question in interviews.

How to use this tool

1. Choose an HTTP method and endpoint in the tool.
2. Add headers, params or a body under the given() step.
3. Send the request and inspect the status, headers and JSON body.
4. Add an assertion on a JSON path and watch it pass or fail.

Worked example

A complete REST Assured test: send a request, then assert on status and a JSON field:

given()
    .baseUri("https://api.example.com")
    .header("Authorization", "Bearer " + token)
    .contentType(ContentType.JSON)
.when()
    .get("/users/1")
.then()
    .statusCode(200)
    .body("user.id", equalTo(1))
    .body("user.email", containsString("@"));

Common mistakes to avoid

• Hard-coding the base URI and token in every test instead of a shared RequestSpecification.
• Asserting only on the status code and ignoring the response body.
• Building JSON bodies as raw strings instead of serializing POJOs.
• Not validating the response against a JSON schema, so silent contract changes slip through.

Frequently asked questions

Related guides & tools