REST Assured Interview Questions: API Testing Guide 2026 (70+ Q&A)

70+ REST Assured Interview Questions (2026) — Beginner to Senior SDET

If you have an automation interview coming up, REST Assured interview questions will be the centrepiece of your technical round — not a warm-up.

API testing is no longer optional for QA engineers in 2026. With microservices dominating system design, every company — from Infosys and TCS to fast-growing product startups in Pune and Bangalore — expects you to write, debug, and design API tests from day one. REST Assured is the tool they test you on, which is exactly why mastering REST Assured interview questions is the single highest-leverage thing you can do before your next interview.

Most candidates preparing for REST Assured interview questions do it the wrong way. They memorise a list of definitions, walk into the interview, and then freeze when the interviewer says: “Show me how you’d design a scalable REST Assured framework for a CI/CD pipeline.” Definitions don’t answer that. Experience does.

This guide covers 70+ REST Assured interview questions and answers — the only REST Assured interview questions resource you need — the same ones asked in actual technical rounds — written the way you should deliver them out loud, not just read them on a screen. It goes from absolute basics all the way to OAuth 2.0, POJO classes, API chaining, Cucumber integration, parallel execution, and architect-level framework design that interviewers at product companies genuinely probe.

Whether you are a fresher appearing for your first automation role or a senior SDET targeting an architect position, this is the only REST Assured interview questions guide you need in 2026.

New to REST Assured? Before diving into these REST Assured interview questions, set up your environment first with our REST Assured Tutorial: Complete Beginner’s Guide (2026).

Table of Contents

1. Why REST Assured Interview Questions Dominate Automation Rounds
2. REST Assured Fundamentals — What Every Interview Starts With
3. REST Assured Interview Questions 1–20 — Beginner Level (Fundamentals)
4. REST Assured Interview Questions 21–35 — Intermediate Level (Frameworks & Auth)
5. REST Assured Interview Questions 36–50 — Advanced Level (Schema, OAuth, CI/CD)
6. REST Assured Interview Questions 51–70 — Architect & Framework Design
7. Scenario-Based REST Assured Interview Questions
8. Common Mistakes Candidates Make in REST Assured Interviews
9. Best Practices for Senior Engineers
10. Quick Revision Cheat Sheet
11. What to Learn Next
12. Conclusion
13. External Resources & Official References

1. Why REST Assured Interview Questions Dominate Automation Rounds

Before the questions, understand why this topic appears in every serious interview in 2026.

API testing has shifted from being a “nice to have” to a core mandatory requirement for every QA automation role. Modern applications are built on microservices architectures where hundreds of APIs communicate with each other constantly. A QA engineer who cannot test APIs is operating at half capacity — and hiring managers know it.

REST Assured interview questions are designed to test three distinct things simultaneously:

Conceptual clarity — REST Assured interview questions are designed to test whether you understand what you are doing and why. An interviewer asking “What is the difference between queryParam and pathParam?” is not just asking about syntax. They want to know if you understand how URLs are structured.

Hands-on coding ability — REST Assured interview questions always include live coding. Can you write REST Assured test code without looking at documentation? REST Assured interview questions almost always include a live coding component. Knowing the API by heart is non-negotiable.

Framework thinking — The hardest REST Assured interview questions probe this. Can you scale REST Assured beyond individual tests into a maintainable, reusable framework? Senior REST Assured interview questions focus almost entirely on RequestSpecification, ResponseSpecification, data-driven approaches, and CI/CD integration.

Companies like Infosys, TCS, Wipro, Cognizant, and every major product company hiring in Pune, Bangalore, Hyderabad, and Chennai include REST Assured interview questions as a standard filter. Candidates who genuinely master these questions clear technical rounds that eliminate 70% of other applicants.

2. REST Assured Fundamentals — What Every Interview Starts With

Before you tackle any REST Assured interview question, lock these fundamentals in your memory. Interviewers use them as warm-up questions to gauge your baseline — a weak answer here signals a weak candidate before the real questions even begin.

What is REST Assured?

REST Assured is an open-source Java-based library for testing and validating RESTful web services, created by Johan Haleby. It abstracts the complexity of HTTP communication behind a fluent, readable DSL (Domain Specific Language). The BDD-style syntax — given(), when(), then() — mirrors Gherkin language, making REST Assured tests self-documenting and readable by non-technical stakeholders.

Before REST Assured, testing APIs in Java required 30–50 lines of boilerplate with Apache HttpClient. REST Assured reduces that to 3–5 lines.

🔗 REST Assured Official GitHub | REST Assured Official Docs

Maven Dependency — Always Have This Ready

Every REST Assured interview may begin with “How do you add REST Assured to your project?” — have this memorised:

<!-- REST Assured Core -->
<dependency>
    <groupId>io.rest-assured</groupId>
    <artifactId>rest-assured</artifactId>
    <version>5.4.0</version>
    <scope>test</scope>
</dependency>

<!-- JSON Path -->
<dependency>
    <groupId>io.rest-assured</groupId>
    <artifactId>json-path</artifactId>
    <version>5.4.0</version>
</dependency>

<!-- XML Path -->
<dependency>
    <groupId>io.rest-assured</groupId>
    <artifactId>xml-path</artifactId>
    <version>5.4.0</version>
</dependency>

<!-- JSON Schema Validator -->
<dependency>
    <groupId>io.rest-assured</groupId>
    <artifactId>json-schema-validator</artifactId>
    <version>5.4.0</version>
</dependency>

<!-- TestNG -->
<dependency>
    <groupId>org.testng</groupId>
    <artifactId>testng</artifactId>
    <version>7.8.0</version>
    <scope>test</scope>
</dependency>

🔗 Always check Maven Central for the latest stable version before your interview. Saying “5.4.0” in 2026 signals you are current.

3. REST Assured Interview Questions 1–20 — Beginner Level

Every recruiter screening for API automation roles starts with these beginner REST Assured interview questions. They cover the core syntax, BDD structure, HTTP methods, and assertion patterns — the building blocks everything else is built on.

These beginner REST Assured interview questions are what you will face in every first-round screening. Answer all of these confidently — a weak answer on any beginner question kills your credibility for the harder ones.

Q1. What is REST Assured and why is it used in API testing?

REST Assured is a Java DSL library built specifically for testing RESTful web services. It supports all HTTP methods, handles JSON and XML parsing out of the box, and integrates with every major Java testing framework. The BDD-style syntax makes REST Assured tests self-documenting — even non-technical stakeholders can read and understand what is being tested.

import io.restassured.RestAssured;
import static io.restassured.RestAssured.*;
import static org.hamcrest.Matchers.*;

RestAssured.baseURI = "https://reqres.in";

given()
    .header("Content-Type", "application/json")
.when()
    .get("/api/users/2")
.then()
    .statusCode(200)
    .body("data.id", equalTo(2))
    .body("data.first_name", equalTo("Janet"));

🎯 Interview Takeaway: “The given-when-then structure in REST Assured interview questions is not coincidental — REST Assured follows Given-When-Then from BDD, which means even non-technical stakeholders can read our API tests. This is a significant advantage in Agile teams where POs review test coverage.”

🔗 REST Assured Official Documentation

Q2. What are the main features of REST Assured?

• • BDD-style syntax — given(), when(), then() makes tests readable and self-documenting
  • Built-in assertions — Hamcrest matchers for status codes, headers, response body, and response time
  • JSON and XML support — JsonPath and XmlPath included out of the box — no extra libraries needed
  • Authentication support — Basic Auth, Digest Auth, OAuth 1.0/2.0, Bearer tokens, form auth
  • Request/Response logging — granular logging control including log-on-failure only
  • Schema validation — validate JSON responses against a JSON Schema for contract testing
  • RequestSpecification / ResponseSpecification — reusable configurations eliminating duplication

Interview note: When this REST Assured interview question comes up, list all seven features — most candidates name three and stop. Completeness signals depth.

given()
    .header("Content-Type", "application/json")
    .queryParam("page", 1)
    .log().all()
.when()
    .get("https://reqres.in/api/users")
.then()
    .log().ifError()
    .statusCode(200)
    .contentType(ContentType.JSON)
    .body("page", equalTo(1))
    .body("data.size()", greaterThan(0))
    .time(lessThan(3000L));

Q3. How do you send a GET request using REST Assured?

When answering this REST Assured interview question, the detail that impresses: always set baseURI globally rather than hardcoding the full URL in every test — this makes switching between dev, staging, and production a single line change.

RestAssured.baseURI = "https://reqres.in";

// Simple GET
given()
.when()
    .get("/api/users/2")
.then()
    .statusCode(200);

// GET with query parameters
given()
    .queryParam("page", 2)
    .queryParam("per_page", 6)
.when()
    .get("/api/users")
.then()
    .statusCode(200)
    .body("page", equalTo(2));

// GET with path parameter
given()
    .pathParam("userId", 3)
.when()
    .get("/api/users/{userId}")
.then()
    .statusCode(200)
    .body("data.id", equalTo(3));

🔗 Practice with ReqRes.in — all code examples in this guide work against this free public API.

Q4. How do you validate the response status code?

Status code validation is the first thing asked in REST Assured interview questions about response handling. It is mandatory in every API test. Always validate status code first — a 500 response can still return a JSON body, and without this check your test might incorrectly pass.

• • • 2xx — Success (200 OK, 201 Created, 204 No Content)
    • 4xx — Client error (400 Bad Request, 401 Unauthorized, 404 Not Found)
    • 5xx — Server error (500 Internal Server Error)

// 200 OK
given().when().get("https://reqres.in/api/users/2").then().statusCode(200);

// 201 Created
given()
    .contentType("application/json")
    .body("{ \"name\": \"Ajit\", \"job\": \"QA Lead\" }")
.when()
    .post("https://reqres.in/api/users")
.then()
    .statusCode(201);

// 404 Not Found
given().when().get("https://reqres.in/api/users/999").then().statusCode(404);

// Flexible validation with Hamcrest
given().when().get("https://reqres.in/api/users/2")
.then().statusCode(anyOf(is(200), is(201)));

Q5. What is the difference between given(), when(), and then()?

This is one of the most frequently asked beginner-level REST Assured interview questions because it tests both your library knowledge and your understanding of BDD principles.

• • • given() — Setup phase: headers, query params, path params, request body, auth, content type, base URI, logging, SSL config
    • when() — Action phase: specify the HTTP method — get(), post(), put(), delete(), patch()
    • then() — Validation phase: status code, body assertions, headers, response time, content type, value extraction

given()                                        // SETUP
    .header("Authorization", "Bearer " + token)
    .contentType("application/json")
    .body("{ \"name\": \"Ajit\" }")

.when()                                        // ACTION
    .post("https://reqres.in/api/users")

.then()                                        // VALIDATION
    .statusCode(201)
    .body("name", equalTo("Ajit"));

🎯 Interview Takeaway: “This is one of the most tested REST Assured interview questions because it reveals BDD understanding. The given-when-then structure is not just syntactic sugar — it enforces separation of concerns in test design. Setup, action, and validation are clearly separated, which makes tests easier to read, maintain, and debug when they fail.”

Q6. How do you add query parameters in REST Assured?

Query parameters are key-value pairs appended to the URL after a ? symbol — used to filter, sort, or paginate results. For more than three parameters, use queryParams(Map) — it keeps code cleaner and allows building the parameter map dynamically from test data.

// Single parameter
given()
    .queryParam("page", 2)
.when()
    .get("https://reqres.in/api/users")
.then()
    .statusCode(200)
    .body("page", equalTo(2));

// Multiple parameters using Map (preferred for 3+ params)
Map<String, Object> params = new HashMap<>();
params.put("page", 1);
params.put("per_page", 3);

given()
    .queryParams(params)
.when()
    .get("https://reqres.in/api/users")
.then()
    .statusCode(200)
    .body("data.size()", equalTo(3));

Q7. How do you send path parameters in REST Assured?

Path parameters are dynamic values embedded directly in the URL path — used to identify a specific resource. Unlike query parameters which filter results, path parameters say which resource you want.

Key difference to remember for interviews: /users/2 — path param (which user). /users?role=admin — query param (filter users by role).

// Single path parameter
given()
    .pathParam("id", 2)
.when()
    .get("https://reqres.in/api/users/{id}")
.then()
    .statusCode(200)
    .body("data.id", equalTo(2));

// Multiple path parameters using Map
Map<String, Object> pathParams = new HashMap<>();
pathParams.put("version", "v1");
pathParams.put("userId", 5);

given()
    .pathParams(pathParams)
.when()
    .get("https://api.example.com/{version}/users/{userId}")
.then()
    .statusCode(200);

Q8. How do you validate the response body in REST Assured?

Response body validation uses JsonPath (GPath syntax) and Hamcrest matchers to verify any field in any JSON structure — simple strings, integers, booleans, arrays, nested objects, and collections.

Response body validation is the most common REST Assured interview question in basic rounds.

// Simple field validation
given().when().get("https://reqres.in/api/users/2")
.then()
    .body("data.id", equalTo(2))
    .body("data.first_name", equalTo("Janet"))
    .body("data.email", containsString("@reqres.in"));

// Array size and content
given().when().get("https://reqres.in/api/users?page=1")
.then()
    .body("data.size()", equalTo(6))
    .body("data.id", hasItems(1, 2, 3))
    .body("data.first_name", hasItem("George"));

// Nested object validation
given().when().get("https://jsonplaceholder.typicode.com/users/1")
.then()
    .body("address.city", equalTo("Gwenborough"))
    .body("address.geo.lat", equalTo("-37.3159"))
    .body("company.name", notNullValue());

// Negation — assert fields are absent or empty
given().when().get("https://reqres.in/api/users?page=1")
.then()
    .body("data", not(empty()))
    .body("data[0].email", not(emptyOrNullString()));

🔗 Hamcrest matcher reference: Hamcrest Official Javadoc

Q9. How do you parse a JSON response in REST Assured?

Extracting values is one of the most practical REST Assured interview question topics — essential for API chaining — where one response feeds the next request. This is one of the most practically tested REST Assured interview questions in live coding rounds.

// Method 1 — Response object (use when you need multiple values)
Response response = get("https://reqres.in/api/users/2");
String firstName = response.jsonPath().getString("data.first_name");
List<Integer> ids = response.jsonPath().getList("data.id");

// Method 2 — Inline extract (clean, single value)
String email =
    given().when().get("https://reqres.in/api/users/2")
    .then().extract().path("data.email");

// Method 3 — GPath filter (interview favourite — shows real depth)
String username =
    given().when().get("https://jsonplaceholder.typicode.com/users")
    .then().extract().path("find { it.id == 5 }.username");

Q10. What is the Response object in REST Assured?

The Response object is a REST Assured interview question topic that reveals real hands-on experience. It holds the complete API response — status code, headers, cookies, and body. It is essential when you need to extract multiple values from the same response or chain API calls.

Response response = get("https://reqres.in/api/users/2");

int statusCode     = response.getStatusCode();       // 200
String body        = response.getBody().asString();  // full JSON string
String contentType = response.getContentType();      // application/json
String userId      = response.jsonPath().getString("data.id");
String email       = response.path("data.email");

Q11. How do you handle headers in REST Assured?

given()
    .header("Authorization", "Bearer " + token)
    .header("Accept", "application/json")
    .header("X-Custom-Header", "value")
.when()
    .get("https://reqres.in/api/users");

// Validate response headers in then()
given().when().get("https://reqres.in/api/users/2")
.then()
    .header("Content-Type", containsString("application/json"))
    .header("Cache-Control", notNullValue());

Q12. How do you perform a POST request with a JSON body?

POST creates new resources. Always set contentType(ContentType.JSON) — without it, the server will not know how to parse your request body and will return a 400 or 415 error.

String requestBody = "{ \"name\": \"Ajit Marathe\", \"job\": \"QA Lead\" }";

given()
    .contentType("application/json")
    .body(requestBody)
.when()
    .post("https://reqres.in/api/users")
.then()
    .statusCode(201)
    .body("name", equalTo("Ajit Marathe"))
    .body("id", notNullValue())
    .body("createdAt", notNullValue());

Q13. What is Content-Type and how do you set it in REST Assured?

Content-Type specifies the format of the request body. Mandatory for POST and PUT requests. Incorrect Content-Type causes parsing failures on the server side — a very common bug that shows up in REST Assured interview questions about debugging.

// Using string literal
given().contentType("application/json");

// Using ContentType enum (preferred — type-safe, no typos)
given().contentType(ContentType.JSON);
given().contentType(ContentType.XML);
given().contentType(ContentType.TEXT);

Q14. How do you log requests and responses in REST Assured?

Logging is the first tool you reach for when a test fails in CI/CD. The trick interviewers expect: use log().ifValidationFails() in production frameworks — not log().all() — to keep pipeline logs readable.

// Log everything (use only for local debugging)
given()
    .log().all()
.when()
    .get("https://reqres.in/api/users")
.then()
    .log().all()
    .statusCode(200);

// Log only when test fails (use this in production/CI frameworks)
given()
    .log().ifValidationFails()
.when()
    .get("https://reqres.in/api/users")
.then()
    .log().ifValidationFails()
    .statusCode(200);

// Log specific parts
given()
    .log().headers()   // only headers
    .log().body()      // only body
    .log().uri()       // only URL

🎯 Interview Takeaway: “In production frameworks I use log().ifValidationFails() to keep CI logs clean. Full logging floods the pipeline and makes real failures hard to spot. Local debugging is where log().all() belongs.”

Q15. How do you validate response time in REST Assured?

Response time validation ensures APIs meet SLA requirements — this is increasingly asked in REST Assured interview questions as performance awareness has become a QA expectation, not just a dev concern.

// REST Assured interview question — validate SLA compliance
given().when().get("https://reqres.in/api/users")
.then()
    .statusCode(200)
    .time(lessThan(2000L));   // Must respond within 2 seconds

// Combine with functional assertions
given().when().get("https://reqres.in/api/users/2")
.then()
    .statusCode(200)
    .body("data.id", equalTo(2))
    .time(lessThan(3000L));

Q16. What is Hamcrest and how does it work with REST Assured?

Hamcrest is an assertion library that provides readable matcher methods. It is so deeply integrated into REST Assured that knowing the key matchers by heart is non-negotiable for any REST Assured interview question involving body validation.

🔗 Full Hamcrest Matcher Reference

Q17. How do you extract values from a REST Assured response?

Extracted values drive the next API call — for example, extracting a created user’s ID for a follow-up GET, PUT, or DELETE. This pattern is called API chaining and appears in almost every real REST Assured interview round as a live coding exercise.

// Extract a single value after POST
String userId =
    given()
        .contentType("application/json")
        .body("{ \"name\": \"Ajit\" }")
    .when()
        .post("https://reqres.in/api/users")
    .then()
        .statusCode(201)
        .extract()
        .path("id");

// Extract full response for multiple reuses
Response response =
    given().when().get("https://reqres.in/api/users/2")
    .then().extract().response();

String email = response.path("data.email");
int    id    = response.path("data.id");

Q18. What is RequestSpecification and how do you use it?

RequestSpecification is the REST Assured interview question answer that separates junior from senior engineers. It defines reusable request configurations — base URI, headers, auth — shared across all tests. If your REST Assured framework does not use specifications, you end up duplicating setup logic across hundreds of tests.

RequestSpecification requestSpec = new RequestSpecBuilder()
    .setBaseUri("https://reqres.in")
    .setContentType(ContentType.JSON)
    .addHeader("Authorization", "Bearer " + token)
    .log(LogDetail.IF_VALIDATION_FAILS)
    .build();

// Reuse across tests — zero duplication
given().spec(requestSpec).when().get("/api/users/2").then().statusCode(200);
given().spec(requestSpec).body("{ \"name\": \"Ajit\" }").when().post("/api/users").then().statusCode(201);

Q19. What is baseURI and how do you configure it in REST Assured?

// Global config — place in @BeforeSuite or base test class
RestAssured.baseURI  = "https://reqres.in";
RestAssured.basePath = "/api";
RestAssured.port     = 443;

// All tests now auto-resolve:
// given().when().get("/users/2") → https://reqres.in/api/users/2
given().when().get("/users/2").then().statusCode(200);

Q20. How do you handle all HTTP methods in REST Assured?

This REST Assured interview question about HTTP methods is tested in every interview. Key difference: PUT replaces the entire resource. PATCH updates only the specified fields. Accidentally using PUT when you meant PATCH can silently wipe data — this is a real production bug that happens to engineers who don’t understand the difference.

// GET — retrieve (idempotent, no body)
given().when().get("/api/users").then().statusCode(200);

// POST — create (returns 201)
given().contentType(ContentType.JSON).body("{ \"name\": \"Ajit\" }")
    .when().post("/api/users").then().statusCode(201);

// PUT — full update (replaces entire resource, returns 200)
given().contentType(ContentType.JSON)
    .body("{ \"name\": \"Ajit\", \"job\": \"Senior QA\" }")
    .when().put("/api/users/2").then().statusCode(200);

// PATCH — partial update (only sends changed fields, returns 200)
given().contentType(ContentType.JSON).body("{ \"job\": \"Architect\" }")
    .when().patch("/api/users/2").then().statusCode(200);

// DELETE — remove (returns 204 No Content)
given().when().delete("/api/users/2").then().statusCode(204);

4. REST Assured Interview Questions 21–35 — Intermediate Level

These intermediate REST Assured interview questions test practical depth — authentication strategies, specifications, file uploads, data-driven patterns, and the token extraction flows you encounter in real projects every day.

These intermediate REST Assured interview questions appear in second-round technical interviews. They test practical depth — not just “do you know the syntax?” but “have you used this in a real project?”

Q21. How do you handle authentication in REST Assured?

Authentication is one of the most practically tested REST Assured interview questions because every real API uses it. Know all four mechanisms — interviewers often ask you to compare them.

// Basic Authentication
given().auth().basic("username", "password").when().get("/api/protected");

// Bearer Token (OAuth 2.0 / JWT)
given().header("Authorization", "Bearer " + accessToken).when().get("/api/protected");

// OAuth 2.0 — native REST Assured support
given().auth().oauth2(accessToken).when().get("/api/protected");

// API Key in header
given().header("X-API-Key", apiKey).when().get("/api/data");

// API Key as query param
given().queryParam("api_key", apiKey).when().get("/api/data");

// Preemptive Basic Auth — skips the 401 challenge round trip
given().auth().preemptive().basic("username", "password").when().get("/api/protected");

🎯 Interview Takeaway: “In production frameworks, authentication should never be hardcoded. Credentials come from environment variables via System.getenv(), and token generation is centralised in a TokenManager utility class with caching and expiry handling.”

Q22. What is the difference between queryParam and pathParam?

Q23. How do you validate response headers in REST Assured?

Response header validation is a REST Assured interview question that often gets skipped by candidates who only focus on body assertions.

given().when().get("https://reqres.in/api/users/2")
.then()
    .statusCode(200)
    .header("Content-Type", containsString("application/json"))
    .header("Cache-Control", notNullValue())
    .headers("Content-Type",  "application/json; charset=utf-8",
             "Connection",     "keep-alive");

Q24. How do you handle cookies in REST Assured?

Cookie handling is a REST Assured interview question for session-based API testing scenarios.

// Extract a cookie from login response
Response response = given()
    .contentType(ContentType.JSON)
    .body("{ \"email\": \"user@example.com\", \"password\": \"pass\" }")
.when()
    .post("https://api.example.com/login");

String sessionId = response.getCookie("SESSIONID");

// Send the cookie in subsequent requests
given()
    .cookie("SESSIONID", sessionId)
.when()
    .get("https://api.example.com/dashboard")
.then()
    .statusCode(200);

Q25. How do you perform PUT and PATCH requests in REST Assured?

// PUT — send ALL fields (replaces entire resource)
given()
    .contentType(ContentType.JSON)
    .body("{ \"name\": \"Ajit Marathe\", \"job\": \"Lead QA\" }")
.when()
    .put("https://reqres.in/api/users/2")
.then()
    .statusCode(200)
    .body("name", equalTo("Ajit Marathe"))
    .body("updatedAt", notNullValue());

// PATCH — send ONLY what changed (other fields untouched)
given()
    .contentType(ContentType.JSON)
    .body("{ \"job\": \"Architect\" }")
.when()
    .patch("https://reqres.in/api/users/2")
.then()
    .statusCode(200)
    .body("job", equalTo("Architect"));

Q26. How do you handle XML responses in REST Assured?

XML response handling is a REST Assured interview question that tests versatility beyond JSON APIs.

given()
    .accept(ContentType.XML)
.when()
    .get("https://api.example.com/users/1")
.then()
    .contentType(ContentType.XML)
    .body("user.name", equalTo("Ajit"))
    .body("user.role", equalTo("QA Lead"));

// Extract XML value
String name =
    given().when().get("https://api.example.com/users/1")
    .then().extract().path("user.name");

Q27. What is ResponseSpecification and why should you use it?

ResponseSpecification is the REST Assured interview question pair to RequestSpecification — interviewers always ask about both. It defines reusable response validations — status code, content type, SLA — shared across tests so you don’t repeat assertions everywhere. Paired with RequestSpecification, it eliminates nearly all boilerplate from individual test methods.

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

// Reuse in any test
given().spec(requestSpec).when().get("/api/users")
    .then().spec(responseSpec).body("data.size()", greaterThan(0));

given().spec(requestSpec).when().get("/api/users/2")
    .then().spec(responseSpec).body("data.id", equalTo(2));

Q28. How do you handle file upload in REST Assured?

// Single file upload
given()
    .multiPart("file", new File("src/test/resources/testfile.pdf"))
    .contentType("multipart/form-data")
.when()
    .post("https://api.example.com/upload")
.then()
    .statusCode(200)
    .body("filename", notNullValue());

// File upload with additional metadata fields
given()
    .multiPart("file",        new File("src/test/resources/resume.pdf"), "application/pdf")
    .multiPart("name",        "Ajit Marathe")
    .multiPart("description", "QA Lead Resume 2026")
    .header("Authorization",  "Bearer " + token)
    .contentType("multipart/form-data")
.when()
    .post("https://api.example.com/upload")
.then()
    .statusCode(200)
    .body("fileId", notNullValue());

Q29. How do you configure SSL / disable SSL validation in REST Assured?

SSL configuration is a REST Assured interview question that tests environment-awareness. Always clarify: disabled only in test environments.

// Disable SSL validation — test environments only, NEVER in production
given()
    .relaxedHTTPSValidation()
.when()
    .get("https://self-signed.badssl.com/")
.then()
    .statusCode(200);

// Global — disables SSL for all tests in the suite
RestAssured.useRelaxedHTTPSValidation();

🎯 Interview Takeaway: “relaxedHTTPSValidation() is safe in test environments with self-signed certificates. I make sure it is never enabled for production test suites — we use proper certificates there and want SSL errors to surface.”

Q30. How do you use filters in REST Assured?

// Logging filters — capture full request and response to a file
PrintStream fileLog = new PrintStream(new File("target/api-debug.log"));

given()
    .filter(new RequestLoggingFilter(fileLog))  // custom filter — REST Assured interview question topic
    .filter(new ResponseLoggingFilter(fileLog))
.when()
    .get("https://reqres.in/api/users");

// Custom filter — add auth token to every request automatically
given()
    .filter((requestSpec, responseSpec, ctx) -> {
        requestSpec.header("Authorization", "Bearer " + TokenManager.getToken());
        return ctx.next(requestSpec, responseSpec);
    });

Q31. How do you validate a list or array in the response?

Array validation is a REST Assured interview question that tests GPath knowledge beyond simple field assertions.

given().when().get("https://reqres.in/api/users?page=1")
.then()
    .body("data",           hasSize(6))
    .body("data.id",        hasItems(1, 2, 3, 4, 5, 6))
    .body("data.email",     everyItem(containsString("@reqres.in")))
    .body("data.find { it.id == 3 }.first_name", equalTo("Emma"));

Q32. How do you handle form parameters in REST Assured?

Form parameters (application/x-www-form-urlencoded) are used in login forms and legacy APIs. Use formParam() — not body() — otherwise the Content-Type mismatch causes a server-side parsing error.

given()
    .contentType("application/x-www-form-urlencoded")
    .formParam("username", "ajit@example.com")
    .formParam("password", "securepass")
.when()
    .post("https://api.example.com/login")
.then()
    .statusCode(200)
    .body("token", notNullValue());

Q33. How do you extract and reuse an authentication token across tests?

Token extraction and reuse is a core real-world pattern. Generate it once, cache it, reuse across the entire suite — this is a REST Assured interview question that immediately distinguishes engineers with framework experience from those who have only written individual tests.

// In @BeforeSuite or @BeforeClass — generate once
public static String getToken() {
    return given()
        .contentType(ContentType.JSON)
        .body("{ \"email\": \"eve.holt@reqres.in\", \"password\": \"cityslicka\" }")
    .when()
        .post("https://reqres.in/api/login")
    .then()
        .statusCode(200)
        .extract()
        .path("token");
}

// Reuse in every test
String token = getToken();

given()
    .header("Authorization", "Bearer " + token)
.when()
    .get("https://reqres.in/api/users")
.then()
    .statusCode(200);

Q34. How do you handle error responses (4xx / 5xx) in REST Assured?

// Validate 404 error body
given().when().get("https://reqres.in/api/users/999")
.then()
    .statusCode(404)
    .body(equalTo("{}"));

// Validate 400 validation error
given()
    .contentType(ContentType.JSON)
    .body("{ \"email\": \"not-an-email\" }")
.when()
    .post("https://api.example.com/users")
.then()
    .statusCode(400)
    .body("error", containsString("invalid email"));

// Handle multiple valid status codes
given().when().get("https://api.example.com/resource")
.then().statusCode(anyOf(is(200), is(201), is(400)));

Q35. How do you set a global base path in REST Assured?

RestAssured.baseURI  = "https://reqres.in";
RestAssured.basePath = "/api";

// All tests resolve to: https://reqres.in/api/users/2
given().when().get("/users/2").then().statusCode(200);

// Reset after suite
RestAssured.reset(); // clears baseURI, basePath, port back to defaults

5. REST Assured Interview Questions 36–50 — Advanced Level

Advanced REST Assured interview questions test whether you can build production-grade API test frameworks — not just write individual tests. Schema validation, serialization, CI/CD integration, and OAuth 2.0 are the topics that filter senior candidates from mid-level ones.

These REST Assured interview questions appear in final technical rounds. They test whether you have actually built and maintained a REST Assured framework in production — not just written individual tests.

Q36. How do you validate a JSON schema in REST Assured?

JSON schema validation is the difference between testing that your API works today and ensuring it doesn’t silently break tomorrow. It is a REST Assured interview question that immediately signals architect-level thinking.

Step 1: Create src/test/resources/schemas/user-schema.json

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "properties": {
    "data": {
      "type": "object",
      "required": ["id", "email", "first_name", "last_name"],
      "properties": {
        "id":         { "type": "integer" },
        "email":      { "type": "string", "format": "email" },
        "first_name": { "type": "string" },
        "last_name":  { "type": "string" }
      },
      "additionalProperties": false
    }
  }
}

Step 2: Validate in your REST Assured test

import static io.restassured.module.jsv.JsonSchemaValidator.matchesJsonSchemaInClasspath;

given().when().get("https://reqres.in/api/users/2")
.then()
    .statusCode(200)
    .body(matchesJsonSchemaInClasspath("schemas/user-schema.json"));

🔗 JSON Schema Validator — GitHub

Q37. What is Serialization and Deserialization in REST Assured?

Serialization and Deserialization is a REST Assured interview question that confirms hands-on framework experience. Serialization converts a Java POJO into JSON for the request body. Deserialization converts a JSON response back into a Java object. Using POJOs removes string manipulation from test code and lets IDEs catch field name typos at compile time.

// POJO class
public class User {
    private String name;
    private String job;
    // getters and setters
}

// Serialization — Java object → JSON (POST request)
User user = new User();
user.setName("Ajit Marathe");
user.setJob("QA Lead");

given()
    .contentType(ContentType.JSON)
    .body(user)  // REST Assured auto-serializes to JSON
.when()
    .post("https://reqres.in/api/users")
.then()
    .statusCode(201);

// Deserialization — JSON response → Java object (GET request)
User returned =
    given().when().get("https://reqres.in/api/users/2")
    .then().extract().body().as(User.class);

System.out.println(returned.getName());

Q38. How do you use POJO classes effectively in REST Assured automation?

POJO usage is a REST Assured interview question that separates string-manipulation scripts from type-safe frameworks.

// Request POJO
public class CreateUserRequest {
    private String name;
    private String job;
    public CreateUserRequest(String name, String job) {
        this.name = name; this.job = job;
    }
    // getters
}

// Response POJO
public class CreateUserResponse {
    private String name;
    private String job;
    private String id;
    private String createdAt;
    // getters
}

// In test — fully type-safe, no string manipulation
CreateUserRequest request = new CreateUserRequest("Ajit", "QA Lead");

CreateUserResponse response =
    given()
        .contentType(ContentType.JSON)
        .body(request)
    .when()
        .post("https://reqres.in/api/users")
    .then()
        .statusCode(201)
        .extract()
        .as(CreateUserResponse.class);

Assert.assertNotNull(response.getId());
Assert.assertEquals(response.getName(), "Ajit");

Q39. How do you handle dynamic request payloads in REST Assured?

Dynamic payloads are a REST Assured interview question topic that reveals how you handle parameterised test data in real suites.

// Approach 1: HashMap — simple, flexible
Map<String, Object> payload = new HashMap<>();
payload.put("name", "Ajit_" + System.currentTimeMillis());
payload.put("job",  "QA Lead");
payload.put("age",  new Random().nextInt(30) + 20);

given()
    .contentType(ContentType.JSON)
    .body(payload)
.when()
    .post("https://reqres.in/api/users")
.then()
    .statusCode(201);

// Approach 2: Template file replacement — cleaner for complex payloads
String template = new String(Files.readAllBytes(
    Paths.get("src/test/resources/templates/user.json")));
String body = template
    .replace("{{name}}", "Ajit")
    .replace("{{job}}",  "QA Lead");

given().contentType(ContentType.JSON).body(body)
    .when().post("/api/users").then().statusCode(201);

Q40. How do you implement OAuth 2.0 authentication in a REST Assured framework?

OAuth 2.0 is the most common auth mechanism in modern APIs. The pattern — generate token → cache it → reuse across tests → handle expiry — is a REST Assured interview question that separates engineers who have worked on real enterprise APIs from those who have not.

// Step 1: Token generation utility (called once in @BeforeSuite)
public class TokenManager {
    private static String token;
    private static long   tokenExpiry;

    public static synchronized String getToken() {
        if (token == null || System.currentTimeMillis() > tokenExpiry - 300_000) {
            refreshToken();
        }
        return token;
    }

    private static void refreshToken() {
        Response response = given()
            .contentType("application/x-www-form-urlencoded")
            .formParam("client_id",     System.getenv("CLIENT_ID"))
            .formParam("client_secret", System.getenv("CLIENT_SECRET"))
            .formParam("grant_type",    "client_credentials")
        .when()
            .post(System.getenv("TOKEN_URL"))
        .then()
            .statusCode(200)
            .extract().response();

        token       = response.path("access_token");
        int expires = response.path("expires_in");
        tokenExpiry = System.currentTimeMillis() + (expires * 1000L);
    }
}

// Step 2: Use in tests
given()
    .auth().oauth2(TokenManager.getToken())
.when()
    .get("https://api.example.com/secure-data")
.then()
    .statusCode(200);

🎯 Interview Takeaway: “The synchronized keyword is critical here. Without it, parallel threads could each trigger a token refresh simultaneously, causing race conditions. This is a real production bug I’ve seen in frameworks built without thread safety in mind.”

Q41. How do you implement data-driven testing with TestNG DataProvider?

DataProvider integration is a REST Assured interview question that tests TestNG knowledge alongside REST Assured usage.

@DataProvider(name = "userData")
public Object[][] userData() {
    return new Object[][] {
        {"Ajit Marathe", "QA Lead", 201},
        {"Rahul Sharma",  "SDET",   201},
        {"",              "QA",     400},   // empty name — expect 400
        {"Valid Name",    "",       400},   // empty job  — expect 400
    };
}

@Test(dataProvider = "userData")
public void testCreateUser(String name, String job, int expectedStatus) {
    Map<String, String> body = new HashMap<>();
    body.put("name", name);
    body.put("job",  job);

    given()
        .spec(requestSpec)
        .body(body)
    .when()
        .post("/api/users")
    .then()
        .statusCode(expectedStatus);
}

🔗 TestNG Official Documentation

Q42. How do you integrate REST Assured with TestNG?

public class BaseTest {
    protected static RequestSpecification requestSpec;
    protected static String token;

    @BeforeSuite
    public void setup() {
        RestAssured.baseURI = ConfigManager.get("base.uri");
        token = TokenManager.getToken();

        requestSpec = new RequestSpecBuilder()
            .setContentType(ContentType.JSON)
            .addHeader("Authorization", "Bearer " + token)
            .log(LogDetail.IF_VALIDATION_FAILS)
            .build();
    }

    @AfterSuite
    public void teardown() {
        RestAssured.reset();
    }
}

public class UserTest extends BaseTest {
    @Test(groups = {"smoke", "regression"}, priority = 1)
    public void testGetUser() {
        given()
            .spec(requestSpec)
        .when()
            .get("/api/users/2")
        .then()
            .statusCode(200)
            .body("data.id", equalTo(2));
    }
}

Q43. How do you integrate REST Assured with Cucumber (BDD)?

Feature file:

Feature: User API

  Scenario: Get user by ID
    Given the API is available
    When I request user with id 2
    Then the status code should be 200
    And the first name should be "Janet"

Step definitions:

public class UserSteps {
    private Response response;

    @Given("the API is available")
    public void setupApi() {
        RestAssured.baseURI = "https://reqres.in";
    }

    @When("I request user with id {int}")
    public void getUser(int userId) {
        response = given()
            .pathParam("id", userId)
        .when()
            .get("/api/users/{id}");
    }

    @Then("the status code should be {int}")
    public void verifyStatus(int expectedStatus) {
        response.then().statusCode(expectedStatus);
    }

    @And("the first name should be {string}")
    public void verifyFirstName(String firstName) {
        response.then().body("data.first_name", equalTo(firstName));
    }
}

🔗 For a complete BDD implementation guide, read our Cucumber Automation Framework – Complete Beginner to Advanced Guide.

Q44. How do you handle API chaining in REST Assured?

API chaining is the most common live coding exercise in REST Assured interview questions for experienced engineers. The interviewer gives you a scenario — “create a user, update them, then delete them” — and watches how you pass data between calls.

@Test
public void testEndToEndUserFlow() {
    // Step 1: Create user — capture the generated ID
    String userId =
        given()
            .spec(requestSpec)
            .body("{ \"name\": \"Ajit\", \"job\": \"QA Lead\" }")
        .when()
            .post("/api/users")
        .then()
            .statusCode(201)
            .extract()
            .path("id");

    // Step 2: Update the created user using extracted ID
    given()
        .spec(requestSpec)
        .body("{ \"name\": \"Ajit Marathe\", \"job\": \"Architect\" }")
    .when()
        .put("/api/users/" + userId)
    .then()
        .statusCode(200)
        .body("job", equalTo("Architect"));

    // Step 3: Delete the user — verify it returns 204
    given()
        .spec(requestSpec)
    .when()
        .delete("/api/users/" + userId)
    .then()
        .statusCode(204);
}

Q45. How do you build an API automation framework folder structure with REST Assured?

Framework structure is one of those REST Assured interview questions that many candidates hand-wave over with vague answers. Interviewers at product companies want to see you have actually built and maintained a framework — not just written individual test scripts.

src/
├── main/java/
│   ├── base/           BaseTest.java        — lifecycle, specs, ThreadLocal
│   ├── config/         ConfigManager.java   — environment-aware properties
│   ├── auth/           TokenManager.java    — caching, expiry, refresh
│   ├── models/         UserRequest.java     — POJO request classes
│   │                   UserResponse.java    — POJO response classes
│   └── utils/          JsonUtils.java       — JSON file readers
│                       SLASpecs.java        — response spec tiers
└── test/
    ├── java/
    │   └── tests/      UserTest.java
    │                   AuthTest.java
    │                   OrderTest.java
    └── resources/
        ├── config-dev.properties
        ├── config-staging.properties
        ├── schemas/    user-schema.json
        └── testdata/   users.json

Interview Takeaway: “Each folder has one job. Config reads properties. Auth manages tokens. Models hold POJOs. Utils handle helpers. Tests only test — they never deal with setup, auth, or config directly. When someone joins the team, the folder name tells them exactly where to look.”

Q46. How do you read test data from external JSON and config files?

External test data management is a REST Assured interview question that reveals professional framework experience. Externalising data from test code is non-negotiable. Data changes, environments change — test logic should never need editing just because a base URL or user credential changed.

Multi-environment management is a REST Assured interview question at framework design level — every production framework must handle it.

// ConfigManager — reads environment at runtime
public class ConfigManager {
    private static Properties prop = new Properties();
    private static final String ENV = System.getProperty("env", "dev");

    static {
        try {
            prop.load(new FileInputStream(
                "src/test/resources/config-" + ENV + ".properties"));
        } catch (Exception e) {
            throw new RuntimeException("Config load failed for env: " + ENV, e);
        }
    }

    public static String get(String key) { return prop.getProperty(key); }
}

// Reading a JSON array for data-driven tests
JsonPath jsonPath = new JsonPath(new File("src/test/resources/testdata/users.json"));
List<Map<String, Object>> users = jsonPath.getList("");

for (Map<String, Object> user : users) {
    given()
        .contentType(ContentType.JSON)
        .body(user)
    .when()
        .post(ConfigManager.get("base.uri") + "/api/users")
    .then()
        .statusCode(201);
}

Q47. How do you integrate REST Assured with CI/CD pipelines?

This REST Assured interview question about CI/CD tests whether you have actually shipped automated API tests to production pipelines — not just run them locally on your machine.

# Run all tests
mvn clean test

# Run only smoke tests
mvn clean test -Dgroups=smoke

# Run against staging
mvn clean test -Denv=staging

# Run in parallel with 4 threads
mvn clean test -DthreadCount=4 -Dparallel=methods

# GitHub Actions — full CI pipeline
name: API Regression Tests
on:
  push:
    branches: [main]
  schedule:
    - cron: '0 2 * * *'   # Nightly at 2am

jobs:
  api-tests:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Set up JDK 17
        uses: actions/setup-java@v3
        with:
          java-version: '17'
      - name: Run REST Assured smoke tests
        run: mvn clean test -Dgroups=smoke -Denv=staging
        env:
          CLIENT_ID:     ${{ secrets.CLIENT_ID }}
          CLIENT_SECRET: ${{ secrets.CLIENT_SECRET }}
      - name: Upload Allure report
        uses: actions/upload-artifact@v3
        with:
          name: allure-report
          path: target/allure-results

Interview Takeaway: “Smoke tests run on every push — fast, critical paths only. Full regression runs nightly. Credentials always come from GitHub Secrets or AWS Secrets Manager — never from the codebase. If a credential appears in a log or a git diff, that is a security incident.”

Q48. How do you add Allure reporting to a REST Assured framework?

<!-- pom.xml -->
<dependency>
    <groupId>io.qameta.allure</groupId>
    <artifactId>allure-testng</artifactId>
    <version>2.24.0</version>
</dependency>

@Epic("User Management API")
@Feature("Create User")
public class CreateUserTest extends BaseTest {

    @Test
    @Story("Create valid user")
    @Description("Verify POST /api/users returns 201 with correct data")
    @Severity(SeverityLevel.CRITICAL)
    public void testCreateUser() {
        Allure.step("Send POST request with valid user payload");

        given()
            .spec(requestSpec)
            .body("{ \"name\": \"Ajit\", \"job\": \"QA Lead\" }")
        .when()
            .post("/api/users")
        .then()
            .statusCode(201)
            .body("name", equalTo("Ajit"));
    }
}

// Generate report: mvn allure:serve

Full setup: Allure + TestNG official docs.

Q49. How do you handle different status codes dynamically in REST Assured?

Response response = given().spec(requestSpec).when().get("/api/resource");
int statusCode    = response.getStatusCode();

switch (statusCode) {
    case 200:
        System.out.println("Success: " + response.path("data"));
        break;
    case 404:
        System.out.println("Not found — check the resource ID");
        break;
    case 401:
        System.out.println("Unauthorized — token may have expired");
        // Trigger TokenManager.refreshToken() and retry
        break;
    case 429:
        System.out.println("Rate limited — backing off");
        break;
    case 500:
        Assert.fail("Server error: " + response.getBody().asString());
        break;
    default:
        System.out.println("Unexpected status: " + statusCode);
}

Q50. What are the best practices for REST Assured framework design?

This REST Assured interview question about best practices is where seniors and architects separate themselves from execution-level engineers. Knowing the API is table stakes. Knowing how to structure it for a team of 10 engineers across two years — that is the answer interviewers are looking for.

• • 1. Never hardcode base URI, credentials, or test data — read from config files and environment variables
    2. Use RequestSpecification and ResponseSpecification — eliminate duplication across all tests
    3. Centralise auth in a TokenManager — with caching, expiry detection, and refresh logic
    4. Use POJO classes for request/response — type safety and compile-time error detection
    5. Validate JSON schemas on critical endpoints — catch breaking API changes before they reach consumers
    6. Use log().ifValidationFails() — keeps CI logs clean while capturing full details on failure
    7. Follow SOLID principles — single responsibility for each utility class
    8. Parameterise environments — same codebase runs against dev, staging, and production
    9. Group tests into smoke, regression, integration — run smoke on every commit, regression nightly
    10. Store test data externally — JSON or properties files, never hardcoded inside test classes

6. REST Assured Interview Questions 51–70 — Architect & Framework Design

These architect-level REST Assured interview questions are what separate a senior engineer from an architect. They appear in final rounds at product companies and for lead/architect roles. If you can answer Q51–Q70 with production-grade code, you will clear any REST Assured interview round.

Q51. How do you run REST Assured tests in parallel?

Parallel execution reduces total suite run time — critical in CI/CD pipelines. The most common mistake in this REST Assured interview question: sharing a single RequestSpecification across threads without ThreadLocal protection.

<!-- testng.xml — parallel REST Assured test execution -->
<suite name="API Suite" parallel="methods" thread-count="4">
    <test name="User API Tests">
        <classes>
            <class name="tests.UserTest"/>
            <class name="tests.AuthTest"/>
        </classes>
    </test>
</suite>

// Thread-safe base class — each thread gets its own RequestSpecification
public class BaseTest {
    protected ThreadLocal<RequestSpecification> requestSpec = new ThreadLocal<>();

    @BeforeMethod
    public void setup() {
        requestSpec.set(new RequestSpecBuilder()
            .setBaseUri(ConfigManager.get("base.uri"))
            .setContentType(ContentType.JSON)
            .addHeader("Authorization", "Bearer " + TokenManager.getToken())
            .log(LogDetail.IF_VALIDATION_FAILS)
            .build());
    }

    protected RequestSpecification getSpec() {
        return requestSpec.get();
    }
}

// In test — always use getSpec(), never a shared static field
@Test
public void testGetUser() {
    given()
        .spec(getSpec())
    .when()
        .get("/api/users/2")
    .then()
        .statusCode(200);
}

🎯 Interview Takeaway: “Without ThreadLocal, parallel threads share the same RequestSpecification object. Thread A might add a header, Thread B overwrites it before Thread A makes its call. The resulting failures are intermittent and nearly impossible to debug without understanding this root cause.”

Q52. How do you handle token refresh in a REST Assured framework?

public class TokenManager {
    private static String token;
    private static long   tokenExpiry;

    public static synchronized String getToken() {
        // Refresh if missing or expiring within the next 5 minutes
        if (token == null || System.currentTimeMillis() > tokenExpiry - 300_000) {
            refreshToken();
        }
        return token;
    }

    private static void refreshToken() {
        Response response = given()
            .contentType("application/x-www-form-urlencoded")
            .formParam("client_id",     System.getenv("CLIENT_ID"))
            .formParam("client_secret", System.getenv("CLIENT_SECRET"))
            .formParam("grant_type",    "client_credentials")
        .when()
            .post(System.getenv("TOKEN_URL"))
        .then()
            .statusCode(200)
            .extract().response();

        token       = response.path("access_token");
        int expires = response.path("expires_in"); // seconds
        tokenExpiry = System.currentTimeMillis() + (expires * 1000L);
    }
}

Q53. How do you implement retry logic for flaky API tests?

// TestNG retry analyser
public class RetryAnalyzer implements IRetryAnalyzer {
    private int count = 0;
    private static final int MAX_RETRY = 2;

    @Override
    public boolean retry(ITestResult result) {
        if (count < MAX_RETRY) { count++; return true; }
        return false;
    }
}

@Test(retryAnalyzer = RetryAnalyzer.class)
public void testCreateOrder() {
    given().spec(getSpec()).body(orderPayload)
        .when().post("/api/orders").then().statusCode(201);
}

// Polling for async APIs — using Awaitility
import static org.awaitility.Awaitility.*;

await()
    .atMost(10, SECONDS)
    .pollInterval(1, SECONDS)
    .until(() ->
        given().when().get("/api/orders/" + orderId)
        .then().extract().path("status").equals("PROCESSED")
    );

Q54. How do you manage multiple environments in a REST Assured framework?

// config-dev.properties
// base.uri=https://dev.api.example.com

// config-staging.properties
// base.uri=https://staging.api.example.com

// ConfigManager — reads environment at runtime via -Denv=staging
public class ConfigManager {
    private static Properties prop = new Properties();
    private static final String ENV = System.getProperty("env", "dev");

    static {
        try {
            prop.load(new FileInputStream(
                "src/test/resources/config-" + ENV + ".properties"));
        } catch (Exception e) {
            throw new RuntimeException("Cannot load config for env: " + ENV, e);
        }
    }

    public static String get(String key) { return prop.getProperty(key); }
}

// Run against staging from Jenkins or GitHub Actions:
// mvn clean test -Denv=staging

Q55. How do you attach request and response details to Allure reports in REST Assured?

Simply running REST Assured tests with Allure gives you pass/fail results. Attaching the actual request and response details to the report is what makes debugging fast — especially for CI failures investigated hours later by a different engineer.

// Custom Allure filter — attaches full request and response to every test report
public class AllureRestAssuredFilter extends AllureRestAssured {

    @Override
    public Response filter(FilterableRequestSpecification requestSpec,
                           FilterableResponseSpecification responseSpec,
                           FilterContext filterContext) {

        // Attach request body to Allure report
        if (requestSpec.getBody() != null) {
            Allure.addAttachment("Request Body",
                "application/json", requestSpec.getBody().toString());
        }

        Response response = filterContext.next(requestSpec, responseSpec);

        // Attach response to Allure report
        Allure.addAttachment("Response [" + response.getStatusCode() + "]",
            "application/json", response.getBody().prettyPrint());

        return response;
    }
}

// Register the filter globally in BaseTest
RequestSpecification requestSpec = new RequestSpecBuilder()
    .addFilter(new AllureRestAssuredFilter())   // attaches to every test
    .setBaseUri(ConfigManager.get("base.uri"))
    .setContentType(ContentType.JSON)
    .build();

// Now every REST Assured test automatically attaches request + response to Allure
@Test
@Description("Create user and verify ID is returned")
public void testCreateUser() {
    given()
        .spec(requestSpec)
        .body("{ \"name\": \"Ajit\", \"job\": \"QA Lead\" }")
    .when()
        .post("/api/users")
    .then()
        .statusCode(201)
        .body("id", notNullValue());
    // Request body and response are automatically in the Allure report
}

Interview Takeaway: “Allure pass/fail results tell you a test failed. The attached request and response tell you why. In a team where QA and developers share Allure dashboards, having the full API exchange in the report reduces the back-and-forth between teams from hours to minutes.”

Full reference: Allure + TestNG official docs.

Q56. How do you handle multipart file upload with additional form fields?

Multipart with metadata is an advanced REST Assured interview question for document management API testing.

given()
    .multiPart("file",        new File("src/test/resources/resume.pdf"), "application/pdf")
    .multiPart("name",        "Ajit Marathe")
    .multiPart("description", "QA Lead Resume 2026")
    .multiPart("category",    "documents")
    .header("Authorization",  "Bearer " + token)
    .contentType("multipart/form-data")
.when()
    .post("https://api.example.com/upload")
.then()
    .statusCode(200)
    .body("fileId",   notNullValue())
    .body("fileName", equalTo("resume.pdf"))
    .body("size",     greaterThan(0));

Q57. How do you test GraphQL APIs with REST Assured?

// GraphQL query
String query = "{ \"query\": \"{ user(id: 2) { id name email } }\" }";

given()
    .contentType(ContentType.JSON)
    .header("Authorization", "Bearer " + token)
    .body(query)
.when()
    .post("https://api.example.com/graphql")
.then()
    .statusCode(200)
    .body("data.user.id",    equalTo(2))
    .body("data.user.email", notNullValue())
    .body("errors",          nullValue()); // No GraphQL errors

Q58. REST Assured vs Karate vs Postman — How do you answer this in an interview?

🎯 Interview Takeaway: “I choose REST Assured when the team is Java-based and needs deep framework integration — custom auth, data-driven testing with POJOs, and parallel execution. Karate is better for teams that want BDD API testing without Java expertise. Postman is for exploratory testing, not CI/CD regression suites.”

Q59. How do you implement contract testing with REST Assured?

// user-contract.json in src/test/resources/schemas/
// {
//   "$schema": "http://json-schema.org/draft-07/schema#",
//   "type": "object",
//   "required": ["data"],
//   "properties": {
//     "data": {
//       "type": "object",
//       "required": ["id", "email", "first_name", "last_name"],
//       "additionalProperties": false
//     }
//   }
// }

@Test
public void verifyUserApiContract() {
    given()
    .when()
        .get("https://reqres.in/api/users/2")
    .then()
        .statusCode(200)
        .body(matchesJsonSchemaInClasspath("schemas/user-contract.json"));
}

🎯 Interview Takeaway: “Contract testing catches breaking API changes before they reach consumers — it’s a safety net for microservices teams. If the provider adds a field marked additionalProperties: false, this test fails immediately and the team is notified before any consumer breaks in production.”

Q60. How do you handle API versioning in a REST Assured framework?

// Version via URL — configurable from properties
String apiVersion = ConfigManager.get("api.version"); // "v1" or "v2"

given().when().get("/api/" + apiVersion + "/users/2").then().statusCode(200);

// Version via header (content negotiation)
given()
    .header("Accept", "application/vnd.api+json;version=2")
.when()
    .get("/api/users/2")
.then()
    .statusCode(200);

Q61. How do you test negative scenarios and boundary conditions?

Negative and boundary testing is a REST Assured interview question topic that reveals QA maturity beyond happy-path thinking.

// Missing required field
given()
    .contentType(ContentType.JSON)
    .body("{ \"job\": \"QA Lead\" }")  // name is missing
.when()
    .post("https://reqres.in/api/users")
.then()
    .statusCode(anyOf(is(400), is(422)));

// Maximum field length boundary
String longName = "A".repeat(256);
given()
    .contentType(ContentType.JSON)
    .body("{ \"name\": \"" + longName + "\", \"job\": \"QA\" }")
.when()
    .post("/api/users")
.then()
    .statusCode(anyOf(is(400), is(422)));

// Unauthorized access with invalid token
given()
    .header("Authorization", "Bearer invalid-token-xyz")
.when()
    .get("/api/protected-resource")
.then()
    .statusCode(401);

Q62. How do you validate response time SLAs across your REST Assured framework?

// SLA tiers — architect REST Assured interview question topic
public class SLASpecs {
    public static ResponseSpecification critical() {  // Login, payment — 1s
        return new ResponseSpecBuilder()
            .expectStatusCode(200).expectContentType(ContentType.JSON)
            .expectResponseTime(lessThan(1000L)).build();
    }
    public static ResponseSpecification standard() {  // General APIs — 3s
        return new ResponseSpecBuilder()
            .expectStatusCode(200).expectContentType(ContentType.JSON)
            .expectResponseTime(lessThan(3000L)).build();
    }
    public static ResponseSpecification batch() {     // Reports — 10s
        return new ResponseSpecBuilder()
            .expectStatusCode(200)
            .expectResponseTime(lessThan(10000L)).build();
    }
}

// Apply in tests
@Test
public void testLoginSLA() {
    given().spec(getSpec())
        .body("{ \"email\": \"user@example.com\", \"password\": \"pass\" }")
    .when().post("/api/login")
    .then().spec(SLASpecs.critical());  // Login must be under 1 second
}

Q63. How do you debug a failing REST Assured test in CI/CD?

// Structured debug output on failure
Response response = given().spec(getSpec()).when().post("/api/users");

if (response.getStatusCode() != 201) {
    System.out.println("=== REST Assured Test Failure Debug ===");
    System.out.println("Status  : " + response.getStatusCode());
    System.out.println("Headers : " + response.getHeaders());
    System.out.println("Body    : " + response.getBody().prettyPrint());
    Assert.fail("Expected 201 but got " + response.getStatusCode());
}

// File-based logging filter (captures full exchange to target/api-debug.log)
PrintStream fileLog = new PrintStream(new File("target/api-debug.log"));
given()
    .filter(new RequestLoggingFilter(fileLog))
    .filter(new ResponseLoggingFilter(fileLog))
.when().post("/api/users");

Q64. How do you handle rate limiting (429 Too Many Requests) in REST Assured?

public Response callWithBackoff(String endpoint) throws InterruptedException {
    int[] waitMs = {1000, 2000, 4000}; // exponential backoff

    for (int wait : waitMs) {
        Response response = given().spec(getSpec()).when().get(endpoint);

        if (response.getStatusCode() != 429) return response;

        System.out.println("Rate limited — retrying in " + wait + "ms");
        Thread.sleep(wait);
    }

    throw new RuntimeException("API still rate-limiting after all retries: " + endpoint);
}

@Test
public void testRateLimitedEndpoint() throws InterruptedException {
    Response response = callWithBackoff("/api/data");
    response.then().statusCode(200);
}

Q65. How do you test role-based API responses in REST Assured?

// Admin sees extra sensitive fields
@Test
public void testAdminResponse() {
    given()
        .header("Authorization", "Bearer " + adminToken)
    .when().get("/api/users/2")
    .then()
        .statusCode(200)
        .body("data.salary",      notNullValue())   // admin-only
        .body("data.internal_id", notNullValue());  // admin-only
}

// Regular user — sensitive fields must be absent
@Test
public void testRegularUserResponse() {
    given()
        .header("Authorization", "Bearer " + userToken)
    .when().get("/api/users/2")
    .then()
        .statusCode(200)
        .body("data.salary",      nullValue())   // must be hidden
        .body("data.internal_id", nullValue());  // must be hidden
}

Q66. How do you validate idempotency in REST Assured?

Idempotency validation is a REST Assured interview question that tests REST principles knowledge at the architectural level.

@Test
public void testPutIsIdempotent() {
    String payload  = "{ \"name\": \"Ajit\", \"job\": \"QA Lead\" }";
    String endpoint = "https://reqres.in/api/users/2";

    String firstJob =
        given().contentType(ContentType.JSON).body(payload)
        .when().put(endpoint)
        .then().statusCode(200).extract().path("job");

    String secondJob =
        given().contentType(ContentType.JSON).body(payload)
        .when().put(endpoint)
        .then().statusCode(200).extract().path("job");

    Assert.assertEquals(firstJob, secondJob,
        "PUT must be idempotent — repeated calls must return identical results");
}

Q67. How do you handle dependent setup and teardown in REST Assured tests?

public class OrderFlowTest extends BaseTest {
    private String userId;
    private String orderId;

    @BeforeClass
    public void createTestUser() {
        userId = given().spec(getSpec())
            .body("{ \"name\": \"Test User\", \"job\": \"Tester\" }")
        .when().post("/api/users")
        .then().statusCode(201).extract().path("id");
    }

    @Test(priority = 1)
    public void testCreateOrder() {
        orderId = given().spec(getSpec())
            .body("{ \"userId\": \"" + userId + "\", \"item\": \"laptop\" }")
        .when().post("/api/orders")
        .then().statusCode(201).extract().path("orderId");

        Assert.assertNotNull(orderId);
    }

    @Test(priority = 2, dependsOnMethods = "testCreateOrder")
    public void testGetOrder() {
        given().spec(getSpec()).when().get("/api/orders/" + orderId)
        .then().statusCode(200).body("status", equalTo("PENDING"));
    }

    @AfterClass(alwaysRun = true)  // CRITICAL — runs even if tests failed
    public void cleanup() {
        if (orderId != null) given().spec(getSpec()).when().delete("/api/orders/" + orderId);
        if (userId  != null) given().spec(getSpec()).when().delete("/api/users/"  + userId);
    }
}

🎯 Interview Takeaway: “alwaysRun = true on @AfterClass is the answer interviewers look for in this REST Assured interview question — without it, cleanup is skipped when tests fail, leaving orphaned test data in the database that pollutes future runs and causes flaky failures.”

Q68. How do you implement data-driven testing using Excel files in REST Assured?

Excel-driven testing is a REST Assured interview question that only engineers with real QA project experience answer well. JSON files work well for structured test data, but many QA teams — especially those working with non-technical stakeholders — maintain test data in Excel. REST Assured handles Excel data-driven testing cleanly via Apache POI. This is a real-world REST Assured interview question that tests practical project experience.

<!-- pom.xml — Apache POI for Excel reading -->
<dependency>
    <groupId>org.apache.poi</groupId>
    <artifactId>poi-ooxml</artifactId>
    <version>5.2.3</version>
</dependency>

// ExcelUtils — reads rows from .xlsx into a list of maps
public class ExcelUtils {
    public static List<Map<String, String>> readExcel(String filePath, String sheetName)
            throws Exception {

        List<Map<String, String>> data = new ArrayList<>();

        Workbook workbook = WorkbookFactory.create(new File(filePath));
        Sheet sheet       = workbook.getSheet(sheetName);
        Row headerRow     = sheet.getRow(0);

        for (int i = 1; i <= sheet.getLastRowNum(); i++) {
            Row row = sheet.getRow(i);
            Map<String, String> rowData = new LinkedHashMap<>();

            for (int j = 0; j < headerRow.getLastCellNum(); j++) {
                String key   = headerRow.getCell(j).getStringCellValue();
                String value = row.getCell(j).getStringCellValue();
                rowData.put(key, value);
            }
            data.add(rowData);
        }
        workbook.close();
        return data;
    }
}

// TestNG DataProvider — feeds Excel rows to REST Assured tests
@DataProvider(name = "excelUsers")
public Object[][] excelUsers() throws Exception {
    List<Map<String, String>> rows =
        ExcelUtils.readExcel("src/test/resources/testdata/users.xlsx", "UserData");

    return rows.stream()
        .map(row -> new Object[]{row})
        .toArray(Object[][]::new);
}

@Test(dataProvider = "excelUsers")
public void testCreateUserFromExcel(Map<String, String> userData) {
    given()
        .spec(requestSpec)
        .body(userData)
    .when()
        .post("/api/users")
    .then()
        .statusCode(Integer.parseInt(userData.get("expectedStatus")));
}

Interview Takeaway: “I use Excel-driven tests when business analysts or product owners own the test data — they update the spreadsheet directly and the test suite picks up the changes on the next run without any code change. For developer-owned data, JSON files are cleaner and version-control friendly.”

Q69. How do you run REST Assured tests inside a Docker container?

Running REST Assured tests in Docker ensures consistent execution across developer machines, CI servers, and cloud environments — eliminating “works on my machine” issues. This is an architect-level REST Assured interview question that demonstrates DevOps awareness.

# Dockerfile — containerised REST Assured test runner
FROM maven:3.9.4-eclipse-temurin-17

WORKDIR /app

# Copy project files
COPY pom.xml .
COPY src ./src

# Pre-download all dependencies (cached in Docker layer)
RUN mvn dependency:go-offline -q

# Default command — run smoke tests against staging
CMD ["mvn", "clean", "test", "-Dgroups=smoke", "-Denv=staging"]

# Build the test image
docker build -t rest-assured-tests:latest .

# Run smoke tests against staging
docker run \
  -e CLIENT_ID=your_client_id \
  -e CLIENT_SECRET=your_client_secret \
  -e TOKEN_URL=https://auth.example.com/oauth/token \
  -v $(pwd)/target:/app/target \
  rest-assured-tests:latest \
  mvn clean test -Dgroups=smoke -Denv=staging

# Allure results are in ./target/allure-results on your host machine

# GitHub Actions — using Docker for consistent REST Assured execution
jobs:
  api-tests:
    runs-on: ubuntu-latest
    container:
      image: maven:3.9.4-eclipse-temurin-17
    steps:
      - uses: actions/checkout@v3
      - name: Run REST Assured tests in container
        run: mvn clean test -Dgroups=regression -Denv=staging
        env:
          CLIENT_ID:     ${{ secrets.CLIENT_ID }}
          CLIENT_SECRET: ${{ secrets.CLIENT_SECRET }}

Interview Takeaway: “Docker containerisation is an architect-level REST Assured interview question. It removes the dependency on any specific engineer’s local Maven or Java setup. Every run — local or CI — uses the identical environment. When a REST Assured test passes in Docker locally and fails in CI, the issue is almost always an environment variable or network configuration difference, not the test itself.”

Q70. How do you design a REST Assured framework from scratch for a new project?

Q70 is the ultimate REST Assured interview question for architect-level roles. Your answer must demonstrate planning, design patterns, tooling choices, and delivery thinking — not just individual test code.

Framework folder structure:

src/
├── main/java/
│   ├── base/           BaseTest.java (setup, specs, lifecycle)
│   ├── config/         ConfigManager.java (env-aware properties)
│   ├── auth/           TokenManager.java (caching + expiry)
│   ├── models/         UserRequest.java, OrderResponse.java (POJOs)
│   └── utils/          JsonUtils.java, SLASpecs.java, FileUtils.java
└── test/
    ├── java/tests/     UserTest.java, AuthTest.java, OrderTest.java
    └── resources/
        ├── config-dev.properties
        ├── config-staging.properties
        ├── schemas/    user-schema.json, order-schema.json
        └── testdata/   users.json, orders.json

The 7 layers every production REST Assured framework needs:

// Layer 1+2+3 — Base class with specs, auth, and thread safety
public class BaseTest {
    protected ThreadLocal<RequestSpecification> requestSpec = new ThreadLocal<>();

    @BeforeSuite
    public void globalSetup() {
        RestAssured.baseURI = ConfigManager.get("base.uri");
    }

    @BeforeMethod
    public void setup() {
        requestSpec.set(new RequestSpecBuilder()
            .setContentType(ContentType.JSON)
            .addHeader("Authorization", "Bearer " + TokenManager.getToken())
            .log(LogDetail.IF_VALIDATION_FAILS)
            .build());
    }

    protected RequestSpecification getSpec() { return requestSpec.get(); }

    @AfterSuite
    public void teardown() { RestAssured.reset(); }
}

🎯 Interview Takeaway: “The best REST Assured frameworks are invisible to the test author. A new team member should be able to write a complete API test in 10 lines without knowing anything about auth, config, or environment — the base layer handles all of it. That is the measure of a well-designed framework.”

7. Scenario-Based REST Assured Interview Questions

Scenario-based REST Assured interview questions are asked in final technical rounds. They have no single correct answer — interviewers want to see your reasoning process, not just your syntax recall.

These REST Assured interview questions test how you apply knowledge to real-world problems. They are what interviewers use to distinguish prepared candidates from experienced ones — and they almost always appear in final rounds.

Scenario 1: How do you test an API that requires a token from a previous call?

// Step 1: Login and extract token
String token =
    given()
        .contentType(ContentType.JSON)
        .body("{ \"email\": \"eve.holt@reqres.in\", \"password\": \"cityslicka\" }")
    .when()
        .post("https://reqres.in/api/login")
    .then()
        .statusCode(200)
        .extract()
        .path("token");

// Step 2: Use token for all subsequent calls
given()
    .header("Authorization", "Bearer " + token)
.when()
    .get("https://reqres.in/api/users")
.then()
    .statusCode(200)
    .body("data.size()", greaterThan(0));

Scenario 2: How do you validate all pages of a paginated API?

int page = 1;
int totalPages;

do {
    Response response =
        given()
            .queryParam("page", page)
        .when()
            .get("https://reqres.in/api/users")
        .then()
            .statusCode(200)
            .extract().response();

    totalPages = response.path("total_pages");
    List<Integer> ids = response.path("data.id");

    Assert.assertFalse(ids.isEmpty(), "Page " + page + " should not be empty");
    page++;

} while (page <= totalPages);

Scenario 3: How do you verify a deleted resource is genuinely gone?

// Create a resource
String userId =
    given().spec(getSpec())
        .body("{ \"name\": \"Temp User\", \"job\": \"QA\" }")
    .when().post("/api/users")
    .then().statusCode(201).extract().path("id");

// Delete it
given().spec(getSpec()).when().delete("/api/users/" + userId)
.then().statusCode(204);

// Verify it no longer exists — must return 404
given().spec(getSpec()).when().get("/api/users/" + userId)
.then().statusCode(404);

8. Common Mistakes Candidates Make in REST Assured Interviews

These are the REST Assured interview question mistakes that immediately flag candidates as inexperienced. Knowing the wrong pattern — and the right one — is itself a REST Assured interview question answer at senior level.

1. Using Thread.sleep() for async APIs
Wrong: Thread.sleep(3000). Right: Use Awaitility for polling-based wait with a timeout.

2. Hardcoding base URLs and credentials
Wrong: given().when().get("https://prod.api.com") inside a test. Right: Read from config files via ConfigManager and credentials from System.getenv().

3. Not setting Content-Type on POST/PUT
Wrong: given().body(json).when().post(url). Right: Always add .contentType(ContentType.JSON) — without it servers return 400 or 415.

4. Ignoring status code validation
Wrong: Jumping straight to body assertions. Right: Validate status code first — a 500 response can still return a JSON body that looks valid.

5. No RequestSpecification in large suites
Wrong: Repeating .header("Authorization", token) in every single test method. Right: Define once in RequestSpecBuilder, reuse with given().spec(requestSpec).

6. Storing credentials in source code
Wrong: String password = "mypassword123" committed to a Git repository. Right: System.getenv("API_PASSWORD").

7. Using log().all() in CI/CD pipelines
Wrong: Every test logs full request and response — pipeline output becomes unreadable. Right: log().ifValidationFails() in framework, log().all() only for local debugging.

8. Sharing RequestSpecification across parallel threads
Wrong: A single static RequestSpecification shared by all threads. Right: ThreadLocal<RequestSpecification> — each thread gets its own isolated instance.

9. Best Practices for Senior Engineers

Framework design REST Assured interview questions separate testers from architects. Anyone can write REST Assured API tests. Very few can design systems that scale, survive failures, and support an entire engineering team.

• • 1. Never hardcode base URI, credentials, or test data — read from config files or environment variables
    2. Use RequestSpecification and ResponseSpecification — eliminate duplication across hundreds of tests
    3. Extract authentication to a utility class — with caching, expiry detection, and thread safety
    4. Use POJO classes for request/response — type safety and compile-time error detection
    5. Validate JSON schemas on critical endpoints — contract testing for microservices stability
    6. Use log().ifValidationFails() — keeps CI logs readable while still capturing failures
    7. Follow SOLID principles — Single Responsibility for each utility class
    8. Parameterise environment — same codebase runs against dev, staging, and production
    9. Group tests — smoke, regression, integration. Run smoke on every commit, full regression nightly
    10. Store test data externally — JSON or Excel files, not hardcoded inside test classes

10. Quick Revision Cheat Sheet — REST Assured Interview Questions

Use this table the night before your REST Assured interview questions round — a five-minute scan is faster than re-reading the full guide.

11. What to Learn Next

Once you have mastered these REST Assured interview questions, here is your progression path to architect level:

• • • 🔗 REST Assured Tutorial: Complete Beginner’s Guide (2026) — If you haven’t set up REST Assured yet, start here before anything else
    • 🔗 API Testing Interview Questions — Broader API concepts that complement REST Assured interview questions: REST principles, HTTP methods, status codes, authentication types
    • 🔗 Cucumber Automation Framework Guide — BDD integration with REST Assured using Cucumber and Gherkin
    • 🔗 TestNG Automation Framework Guide — Parallel execution, DataProvider, and enterprise reporting
    • 🔗 Playwright Interview Questions Guide — If your interview also covers UI automation

12. Conclusion — Final Thoughts on REST Assured Interview Questions

After working through all 70 REST Assured interview questions in this guide — from basic GET requests to Docker-containerised parallel execution, here is the most important thing to understand: — they are a lens through which interviewers assess how you think about quality engineering at scale.

At a basic level, any candidate can answer “What is REST Assured?” or “How do you send a GET request?” Those answers filter out people who have never opened the library. But the real REST Assured interview begins at Q21 — when the questions shift from what the library does to how you use it to solve real problems in production frameworks.

The engineers who consistently clear senior and architect-level REST Assured interview rounds share one trait: they have moved beyond syntax. They think in systems. They ask “how do we make this reliable for 50 engineers?” before “how do I make this test pass?” That shift in thinking is what this guide has tried to build — not just answers, but the reasoning behind the answers.

Here is the honest truth about preparing for REST Assured interview questions: reading 70 of them in one sitting will not get you hired. What gets you hired is writing actual code. Set up a local REST Assured project tonight, point it at reqres.in or jsonplaceholder.typicode.com, and work through the examples hands-on. By the time you have written Q1 through Q50 yourself, the architect-level REST Assured interview questions answer themselves.

Memorising REST Assured interview questions does not make you an advanced engineer. Tools like REST Assured do not make you an advanced engineer. Your approach, your design thinking, and your ability to build systems that other engineers can rely on — that is what makes you advanced. Master that, and you will not just clear REST Assured interviews. You will start setting the standard for others.

Good luck with your REST Assured interview questions round. You are better prepared than 90% of candidates who will walk into that room — and the ones who practise the code examples will clear it.

13. External Resources & Official References

Official REST Assured Resources — For Interview Preparation

• • • 🔗 REST Assured GitHub Repository — Primary source. Read the README and Wiki before your interview. Interviewers respect candidates who have read the actual source.
    • 🔗 REST Assured Official Website — Full feature documentation. Bookmark the authentication and schema validation sections.
    • 🔗 REST Assured Javadoc — Complete API reference for advanced REST Assured interview questions about specific methods and parameters.
    • 🔗 REST Assured on Maven Central — Always check for the latest stable version before an interview.

Supporting Libraries Referenced in These REST Assured Interview Questions

• • • 🔗 Hamcrest Official Javadoc — All matchers used in REST Assured assertions. Know equalTo, hasItem, containsString, notNullValue, lessThan, anyOf by heart.
    • 🔗 JSON Schema Validator — GitHub — Powers matchesJsonSchemaInClasspath(). Understand draft-07 schema syntax for contract testing interview questions.
    • 🔗 TestNG Official Documentation — REST Assured integrates tightly with TestNG for DataProvider, parallel execution, and lifecycle hooks.
    • 🔗 Allure Framework — Standard reporting tool paired with REST Assured in production frameworks.

Practice APIs

• • • 🔗 ReqRes.in — The best free REST API for practising REST Assured interview questions hands-on. All code examples in this guide work against it directly.
    • 🔗 JSONPlaceholder — Free fake REST API for posts, users, and comments. Good for practising nested JSON path expressions.
    • 🔗 Postman Echo — Reflects your request back as a response. Excellent for testing headers, query params, and auth configurations.