API Testing Interview
Questions and answers with code.

An API (Application Programming Interface) is a contract that lets two software systems talk to each other. It defines the request format, the response format and the rules for using it.

API testing sends requests directly to the service and checks the response — status code, headers, body, schema and timing — without going through a browser. UI testing drives the actual user interface. API tests are faster, more stable and can catch bugs earlier because they bypass the front end.

REST is an architectural style: stateless, resource-oriented, using standard HTTP methods. SOAP is a strict protocol with its own envelope and WSDL contract. GraphQL lets the client describe the exact shape of the response in one query.

Idempotent means calling it once or many times leaves the server in the same state. That is why retrying a PUT or DELETE is safe, but retrying a POST may create duplicate records.

PUT replaces the entire resource with the body you send. If you leave out a field, it may be set to null or removed, depending on the server.

PATCH applies a partial update. You send only the fields you want to change, and the server merges them with the existing resource.

// Existing user
{ "name": "Ravi", "email": "ravi@example.com", "age": 28 }

// PUT /users/1 — full replace (age will be lost or nulled)
{ "name": "Ravi Kumar", "email": "ravi@example.com" }

// PATCH /users/1 — partial update (age stays 28)
{ "name": "Ravi Kumar" }

Status codes are grouped by their first digit:

• 1xx — informational
• 2xx — success (200 OK, 201 Created, 204 No Content)
• 3xx — redirection (301 Moved Permanently, 302 Found, 304 Not Modified)
• 4xx — client error (400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 409 Conflict, 422 Unprocessable Entity, 429 Too Many Requests)
• 5xx — server error (500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable)

401 Unauthorized means the request lacks valid authentication — no token, expired token, wrong credentials. The server does not know who you are.

403 Forbidden means the server knows who you are but you do not have permission to access that resource. Re-authenticating will not help.

Headers carry metadata about the request or response. They do not hold the main data — that is in the body — but they control how it is processed.

Common request headers:

• Content-Type — the format of the request body (application/json, application/xml)
• Accept — the format the client wants back
• Authorization — the credentials (Bearer token, Basic base64)
• User-Agent — identifies the client

Common response headers:

• Content-Type — the format of the response body
• Cache-Control — caching rules
• Location — where a newly created resource lives (with 201)
• X-RateLimit-Remaining — how many API calls are left in the window

Path parameters are part of the URL path and usually identify a specific resource: /users/42.

Query parameters come after a question mark and usually filter, sort or paginate: /users?role=admin&page=2.

JSON is a lightweight text format using key-value pairs and arrays. It is easy to read and parse, and it is the default for most modern REST APIs.

XML is more verbose, uses tags and attributes, and supports schemas (XSD) and namespaces. It is still common in SOAP and older enterprise systems.

// JSON
{ "id": 1, "name": "Ravi", "role": "admin" }

<!-- XML -->
<user>
  <id>1</id>
  <name>Ravi</name>
  <role>admin</role>
</user>

In Postman and REST Assured, JSON is parsed with JSON path expressions; XML is parsed with XPath.

Authentication answers "who are you?" — it verifies identity through credentials (password, API key, token).

Authorisation answers "what are you allowed to do?" — it checks permissions after identity is confirmed.

In testing: a missing token should give 401; a valid token without the required role should give 403.

For testing, the key scenarios are: valid credentials, missing credentials, expired credentials and insufficient permissions.

A JSON schema describes the expected structure of a JSON response — which fields exist, their types, which are required, and any constraints like minimum length or allowed values.

Validating against a schema catches contract breaks that simple field assertions miss. If the API suddenly returns age as a string instead of a number, a schema test fails immediately even though the field is still present.

{
  "type": "object",
  "required": ["id", "name", "email"],
  "properties": {
    "id":    { "type": "integer" },
    "name":  { "type": "string" },
    "email": { "type": "string", "format": "email" }
  }
}

Postman is a GUI tool for sending HTTP requests and inspecting responses. It is the most common tool for manual API testing and for building quick automation suites.

• Collection — a folder of related requests, usually one collection per API or feature.
• Environment — a set of key-value variables (base URL, token, user ID) that can be switched without editing each request.
• Variables — placeholders like {{baseUrl}} that get replaced at request time.
• Tests tab — JavaScript assertions that run after the response is received.
• Pre-request script — JavaScript that runs before the request, useful for generating tokens or timestamps.

Newman is the command-line runner for Postman collections. You export a collection and environment, then run them from a terminal or a CI job.

newman run UserApi.postman_collection.json \
  -e staging.postman_environment.json \
  --reporters cli,htmlextra

In CI, a Newman step fails the build if any assertion fails, so API regressions are caught before deployment.

REST Assured is a Java library for testing and validating REST APIs. It gives you a fluent given() / when() / then() syntax.

Teams use it over Postman when they need tests inside the same codebase, want to share POJOs and utilities with developers, need complex data setup, or want Maven/TestNG/Jenkins integration with fine-grained reporting.

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

given()
    .baseUri("https://api.example.com")
.when()
    .get("/users/1")
.then()
    .statusCode(200)
    .body("name", notNullValue());

Tests passed · status 200 · body contains name

Add the dependency to your pom.xml. You usually also add TestNG and a JSON schema validator.

<dependency>
  <groupId>io.rest-assured</groupId>
  <artifactId>rest-assured</artifactId>
  <version>5.4.0</version>
  <scope>test</scope>
</dependency>
<dependency>
  <groupId>org.testng</groupId>
  <artifactId>testng</artifactId>
  <version>7.9.0</version>
  <scope>test</scope>
</dependency>

In a base test class, set RestAssured.baseURI and any common headers. Then write tests with given() / when() / then().

You can send the body as a raw string, a Map, or a POJO. POJOs are the cleanest because they are type-safe and reusable.

Map<String, Object> body = new HashMap<>();
body.put("name", "Ravi");
body.put("email", "ravi@example.com");
body.put("role", "admin");

given()
    .baseUri("https://api.example.com")
    .contentType("application/json")
    .body(body)
.when()
    .post("/users")
.then()
    .statusCode(201)
    .body("name", equalTo("Ravi"));

Tests passed · status 201 Created

This is the classic chaining pattern: create a resource, grab its ID from the response, then use that ID in the next call.

// Step 1: create the user and extract the ID
int userId = given()
    .baseUri("https://api.example.com")
    .contentType("application/json")
    .body("{\"name\":\"Ravi\",\"email\":\"ravi@example.com\"}")
.when()
    .post("/users")
.then()
    .statusCode(201)
    .extract().path("id");

// Step 2: use the ID in a GET
given()
    .baseUri("https://api.example.com")
.when()
    .get("/users/" + userId)
.then()
    .statusCode(200)
    .body("name", equalTo("Ravi"));

Tests passed · status 200 OK

Add the json-schema-validator dependency, store your schema in src/test/resources, and use matchesJsonSchemaInClasspath.

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

given()
    .baseUri("https://api.example.com")
.when()
    .get("/users/1")
.then()
    .statusCode(200)
    .body(matchesJsonSchemaInClasspath("user-schema.json"));

Tests passed · response matches schema

Serialisation converts a Java object into JSON for the request body. Deserialisation converts a JSON response into a Java object.

REST Assured uses Jackson or Gson under the hood. When you pass a POJO to body(), it serialises automatically. When you call as(MyPojo.class), it deserialises.

public class User {
    public String name;
    public String email;
}

// serialise: POJO → JSON
User u = new User();
u.name = "Ravi"; u.email = "ravi@example.com";

given().contentType("application/json").body(u)
.when().post("/users")
.then().statusCode(201);

// deserialise: JSON → POJO
User created = get("/users/1").as(User.class);

REST Assured has built-in helpers for Basic and OAuth 2.0, and you can set any custom header directly.

// Basic auth
given().auth().basic("username", "password")
.when().get("/protected")
.then().statusCode(200);

// Bearer token
given().header("Authorization", "Bearer " + token)
.when().get("/profile")
.then().statusCode(200);

// API key in header
given().header("x-api-key", apiKey)
.when().get("/data")
.then().statusCode(200);

In the first request's Tests tab, extract the value and save it as an environment variable. The next request references it with {{variable}}.

const res = pm.response.json();
pm.environment.set("userId", res.id);
pm.test("User created", () => {
    pm.response.to.have.status(201);
});

GET https://api.example.com/users/{{userId}}

A pre-request script runs before the request is sent. It is used to generate dynamic values such as a timestamp, a random ID, or a signed token.

// generate a unique email for each run
const unique = Date.now();
pm.environment.set("email", `user${unique}@example.com`);

This avoids 409 Conflict errors when the same test runs repeatedly against a persistent environment.

Functional API testing checks that the API behaves correctly for a given input — status, body, business rules.

Contract testing checks that two services agree on the shape of their interaction — the request and response structure — without needing both services running. Tools like Pact create a contract from the consumer side and verify it against the provider.

Contract tests catch breaking changes early in microservice environments, before integration tests run.

API mocking means standing up a fake server that returns predefined responses. You use it when the real API is not ready, is unreliable, is expensive to call, or when you need to simulate error conditions that are hard to trigger on the real service.

Postman has built-in mock servers; WireMock and MockServer are common in Java projects. Mocks are for development and testing only — you still need integration tests against the real service.

Rate limiting returns 429 Too Many Requests once a client exceeds the allowed number of calls in a window. To test it:

1. Send requests in a tight loop until the API returns 429.
2. Assert the response includes a Retry-After header and/or X-RateLimit-* headers.
3. Wait for the window to reset and verify normal calls succeed again.
4. Confirm that different API keys or users have independent limits.

Run this against staging, not production, and with an explicit approval from the API owner.

Pagination usually comes in one of two styles:

• Offset/limit — /users?page=2&size=20.
• Cursor-based — /users?after=abc123.

What to test:

1. Page 1 returns the correct number of items.
2. Consecutive pages do not repeat or skip records.
3. The total count or next-cursor matches the actual data.
4. Requesting a page beyond the last returns an empty list or 404, as documented.
5. Invalid page or size values are handled gracefully (400 or default).

The OWASP API Security Top 10 lists the most common API-specific risks. The ones that matter most in day-to-day testing are:

• Broken object level authorisation — a user can access another user's record by changing an ID. Test this explicitly.
• Broken authentication — weak tokens, no expiry, missing token validation.
• Excessive data exposure — the API returns more fields than the client needs, leaking sensitive data.
• Lack of resources and rate limiting — no protection against brute force or abuse.
• Mass assignment — a client can set fields it should not, like role: "admin".

As a tester, the practical checks are: try IDOR by swapping IDs, send a request without a token, send a request with an expired token, and attempt to set restricted fields.

API testing focuses on one service: does this endpoint return the right status, headers and body for valid and invalid input?

Integration testing checks that multiple services or components work together — service A calls service B, the database is updated, the message is queued. It covers the seams between systems, not the internals of one.

In practice, API tests are usually faster and run earlier; integration tests are slower and catch communication and data-flow issues.

Do not hard-code tokens. Fetch a fresh token at the start of the run and reuse it. If the token can expire mid-run, add a refresh step.

public class AuthHelper {
    private static String token;

    public static String getToken() {
        if (token == null) {
            token = given()
                .contentType("application/json")
                .body("{\"username\":\"tester\",\"password\":\"secret\"}")
            .when()
                .post("/auth/login")
            .then()
                .statusCode(200)
                .extract().path("token");
        }
        return token;
    }
}

Layer 1 — Base setup: a base test class that sets base URI, common headers and authentication once.

Layer 2 — API clients: one class per resource (UserApiClient, OrderApiClient) with methods like createUser(), getUser(). Tests call these methods instead of writing raw HTTP.

Layer 3 — Models: POJOs for requests and responses, generated or hand-written. Use Jackson or Gson.

Layer 4 — Utilities: helpers for token retrieval, random data generation, config reading from properties files, and DB assertions if needed.

Layer 5 — Test data: externalise test data to JSON or CSV files so tests are not tied to hard-coded values.

Layer 6 — Tests: TestNG or JUnit tests that call the API clients and assert status, body and schema.

Layer 7 — Reporting and CI: Allure or Extent reports, and a Jenkins or GitHub Actions pipeline that runs the suite on every commit.

Keep configuration in one place, keep tests independent, and always clean up test data.

Separate the concerns:

• Contract tests — verify that the upstream API returns the shape your service expects. Run these independently so you know quickly if the upstream changed.
• Stubbed tests — mock the upstream service with WireMock and test your API's behaviour for success, error and timeout responses. This is fast and deterministic.
• End-to-end tests — run a smaller set against the real upstream in a staging environment. These are slower but catch real integration issues.

Do not make every test depend on a live third-party service — one outage will fail your whole suite.

Async APIs return 202 Accepted and a job ID, then notify completion through a webhook, a message queue or a status endpoint you poll.

• Polling pattern — call the status endpoint with the job ID until it returns completed or failed. Assert on the final payload.
• Webhook pattern — stand up a test listener, trigger the job, and assert the webhook payload matches the expected schema and content.
• Queue pattern — subscribe to the message broker in the test and assert the message is published with the right body.

Always include a timeout. An async test that waits forever will hang the CI pipeline.

Start with a clear goal: how many requests per second at what response time and error rate?

1. Baseline — run a single-user test and record response time for each endpoint.
2. Load test — ramp up to expected peak traffic and check that p95 latency and error rate stay within limits.
3. Stress test — push beyond peak until the system breaks, and note where it breaks.
4. Soak test — run at moderate load for hours to catch memory leaks and connection pool exhaustion.

JMeter and k6 are the common tools. Always test in an environment that matches production, and never run load tests against production without explicit approval.

For PUT and DELETE, idempotency means calling the same request twice should leave the server in the same state.

1. Send the request once and record the response and the resulting server state.
2. Send the exact same request again.
3. Assert that the final server state is identical — not that the response is identical. For DELETE, the second call may return 404 or 204; both are acceptable if the resource is gone.

For POST, idempotency is not required by the spec, but many APIs support an Idempotency-Key header. Test that two POSTs with the same key create only one record.

Each test should create the data it needs and clean up after itself, so tests can run in any order and in parallel.

• Create via API — prefer creating test data through the API itself, so you test the real path.
• Unique identifiers — generate unique emails, usernames or IDs per run to avoid conflicts.
• Teardown — delete the created resources in an @AfterMethod or equivalent, even if the test failed.
• Database reset — for integration tests, a clean database snapshot restored before the suite is the most reliable approach.
• No shared state — never let one test depend on data created by another. That creates order-dependent flakiness.

400 Bad Request means the request itself is malformed — invalid JSON syntax, missing required header, wrong content type. The server cannot even parse the request.

422 Unprocessable Entity means the request is syntactically valid but fails semantic validation — for example, a date of birth in the future, an age below the allowed minimum, or a start date after the end date.

Not all APIs use 422. Some teams return 400 for both. What matters in testing is consistency: check what the API documents and assert accordingly.

File uploads use multipart/form-data. In REST Assured:

given()
    .multiPart("file", new File("src/test/resources/sample.pdf"))
.when()
    .post("/upload")
.then()
    .statusCode(200)
    .body("fileName", equalTo("sample.pdf"));

What to test:

• Valid file type and size upload succeeds.
• Unsupported file type is rejected (415 or 400).
• File exceeding the size limit is rejected (413).
• Download returns the correct content type, content length and file bytes.
• Download of a file you do not own returns 403 or 404, not the file.

API test coverage is not a single number. Track these dimensions:

• Endpoint coverage — how many of the documented endpoints have at least one automated test.
• Method coverage — for each endpoint, are all supported methods tested?
• Status code coverage — for each endpoint, are the success and error codes covered (200, 201, 400, 401, 403, 404, 409)?
• Parameter coverage — are required, optional and boundary values for each parameter tested?
• Auth coverage — is each endpoint tested with valid, missing, expired and insufficient-permission credentials?

A coverage matrix in a spreadsheet or a dashboard is more useful than a single percentage.

Test maintenance is the biggest cost in API automation. Practical habits:

• Assert on the contract, not on every field — validate the schema and the key fields that matter, not the entire response body.
• Centralise endpoints and payloads — if the URL or payload shape changes, you edit one place.
• Use POJOs instead of raw strings — a compile error is easier to fix than a runtime 400.
• Version your tests with the API — run the old suite against the old version until it is retired.
• Fail fast on contract changes — a schema test that fails immediately tells you exactly what changed.

API testing runs before release, in CI or on a staging environment. It verifies correctness for a wide range of inputs and edge cases. It is comprehensive but not continuous.

API monitoring runs continuously in production. It checks that key endpoints are reachable, returning the right status and within expected response time. It is shallow but always on.

You need both: tests catch bugs before users see them; monitoring catches outages and regressions after deployment.

Common versioning styles: URL path (/v1/users), query parameter (/users?version=1), custom header (Accept: application/vnd.api+json;version=1).

What to test:

• Each supported version still works for its documented behaviour.
• Deprecated versions return a warning header (Deprecation, Sunset) if documented.
• Removed versions return 404 or 410 Gone, not a silent fallback.
• A request with an unsupported version returns a clear error, not the latest version.
• Behaviour is consistent — the same request to the same version gives the same response shape.

Step 1 — Check whether the failure is consistent or intermittent. If intermittent, it may be a race condition, a downstream timeout or a resource limit.

Step 2 — Look at the server logs for the exact request that failed. The stack trace usually points to the cause — a null pointer, a constraint violation, a connection pool exhaustion.

Step 3 — Test with minimal valid payload, then add fields one at a time. This isolates which field or combination triggers the failure.

Step 4 — Check for database constraints. A unique index on email will throw a 500 if the API does not catch the duplicate key exception and return 409 instead.

Step 5 — Confirm whether the same request succeeds on a freshly restarted service. If it does, you are likely leaking connections or memory.

Step 1 — Document the behaviour with evidence: the request, the 200 response, and the error payload. This is a design issue, not just a bug.

Step 2 — Raise it with the API owner. The correct behaviour is a 4xx status so that clients, monitoring and gateways can react properly.

Step 3 — In your tests, assert the current behaviour (200 + error body) so the suite passes, but mark it as a known issue and link it to the ticket.

Step 4 — Once fixed, update the tests to assert the new status code and remove the known-issue flag.

Step 5 — Add this to your API review checklist so new endpoints do not repeat the mistake.

Step 1 — Compare environments. CI may point to a different base URL, use a different database, or have different environment variables.

Step 2 — Check for timing issues. CI machines are often slower. Increase timeouts and add explicit waits for async operations.

Step 3 — Check for test pollution. If tests share state and CI runs them in parallel, one test may be deleting data another needs.

Step 4 — Check for hard-coded IDs or emails. Locally these may exist; in CI they may not.

Step 5 — Reproduce the CI run locally with the same environment variables and the same parallel settings. The failure will usually appear.

Step 1 — If there is an OpenAPI/Swagger spec at a standard path (/swagger.json, /openapi.json), import it into Postman. That gives you most of the contract.

Step 2 — If not, observe the UI. Open browser DevTools, use the application, and capture every network request. That reveals the endpoints, headers and payloads the front end uses.

Step 3 — Ask the developer for a sample collection or a few example requests. Most developers have a Postman collection they use themselves.

Step 4 — Probe safely: send a request without a token to see what auth is enforced; send a malformed body to see what validation exists.

Step 5 — Document what you discover and share it. You will be creating the documentation the team was missing.

Step 1 — Reproduce it carefully. Log in as User A, note your own ID, then request User B's ID. Record the exact request and response.

Step 2 — Confirm it is not a false positive. Make sure User B's data is genuinely not visible to User A anywhere else, and that the token used belongs to User A only.

Step 3 — Stop testing once confirmed. Do not enumerate IDs or download data. This is a broken object level authorisation (BOLA/IDOR) issue — a serious vulnerability.

Step 4 — Report through the security channel, not a public ticket. Include the request, response, timestamps and the account used.

Step 5 — After the fix, add an automated test that asserts 403 or 404 when one user requests another user's resource.

Step 1 — Work from the API contract. If there is an OpenAPI spec or a design document, review it and write test cases against the expected behaviour.

Step 2 — Set up a mock server from the spec. Postman and WireMock can both generate mocks from an OpenAPI file. Your tests can be written and run against the mock before the real API exists.

Step 3 — Identify edge cases early — boundary values, invalid types, missing required fields — and share them with the developer. This often improves the implementation before it is written.

Step 4 — Prepare the test data and the environment. When the real API is ready, you only need to switch the base URL.

Step 5 — Once the API is live, run the same suite against it and compare with the mock behaviour.

Step 1 — Check the TLS certificate. Expired, self-signed or wrong-host certificates cause the client to reject the connection.

Step 2 — Check for mixed content. If the API returns URLs pointing to HTTP resources, browsers and some clients will block them.

Step 3 — Check redirects. The HTTP endpoint may redirect to HTTPS, and the client may not follow the redirect or may drop the Authorization header on redirect.

Step 4 — Check TLS version and cipher support. Older clients may not support the TLS version the server requires.

Step 5 — Use curl -v or Postman's console to see the exact TLS handshake failure. That usually identifies the cause immediately.

Step 1 — Reproduce it cleanly: create a resource, delete it, then immediately GET it. If GET returns the resource, the delete did not work.

Step 2 — Confirm by querying the database or the admin API directly, if available. This rules out a caching issue on GET.

Step 3 — Check whether the delete is soft — some APIs mark a record as deleted but keep the row. In that case the GET should return 404; if it still returns 200, the filter is missing.

Step 4 — Write the report with: exact steps, the create response, the delete response, the GET response, and the environment. Include timestamps.

Step 5 — Add a regression test that deletes a resource and asserts the follow-up GET returns 404.

Step 1 — Externalise the base URL, credentials and any environment-specific values into property files or environment variables. Never hard-code them.

Step 2 — Use a Maven profile or a system property to select the environment at run time.

Step 3 — Tag tests that should not run against production — anything that creates or deletes data. Run only read-only smoke tests in production.

Step 4 — Use separate test accounts per environment, and never point production tests at real customer data.

Step 5 — Keep the suite fast in production. A small set of critical-path checks is better than the full regression suite running against live data.

Step 1 — Add logging. Capture the full request and response for each run so you can compare the failing run with a passing one.

Step 2 — Look for time dependence. Tests that depend on today's date, a timestamp within a second, or a token that expires quickly will flake.

Step 3 — Look for shared state. If two tests use the same email or ID, one may run before the other cleans up.

Step 4 — Look for async gaps. If the API is eventually consistent, a GET immediately after a POST may return stale data. Add a retry with backoff, or poll a status endpoint.

Step 5 — Once fixed, run the test 20 times in a row. If it is still flaky, the cause is in the environment or the API, not the test.

Sample response:

{
  "id": 1,
  "name": "Leanne Graham",
  "email": "leanne@example.com",
  "role": "admin"
}

const body = pm.response.json();

pm.test("Name is Leanne Graham", () => {
    pm.expect(body.name).to.eql("Leanne Graham");
});

pm.test("Email is valid format", () => {
    pm.expect(body.email).to.match(/^[^@\s]+@[^@\s]+\.[^@\s]+$/);
});

pm.test("Role is admin", () => {
    pm.expect(body.role).to.be.oneOf(["admin", "user"]);
});

PASS  Name is Leanne Graham
PASS  Email is valid format
PASS  Role is admin

const res = pm.response.json();

pm.test("User created", () => {
    pm.response.to.have.status(201);
});

// save the new user ID for the next request
pm.environment.set("userId", res.id);

// save the auth token from the login response
if (res.token) {
    pm.environment.set("authToken", res.token);
}

The next request uses {{userId}} in the URL and {{authToken}} in the Authorization header.

Request 1 — POST /users (Tests tab):

const created = pm.response.json();
pm.environment.set("newUserId", created.id);

pm.test("Created with correct name", () => {
    pm.expect(created.name).to.eql("Ravi");
});

Request 2 — GET /users/{{newUserId}} (Tests tab):

const fetched = pm.response.json();

pm.test("Fetched user matches created user", () => {
    pm.response.to.have.status(200);
    pm.expect(fetched.id).to.eql(pm.environment.get("newUserId"));
    pm.expect(fetched.name).to.eql("Ravi");
});

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

public class CreateUserTest {
    public static void main(String[] args) {
        String body = """
            {
              "name": "Ravi",
              "email": "ravi@example.com",
              "role": "admin"
            }
            """;

        given()
            .baseUri("https://api.example.com")
            .contentType("application/json")
            .body(body)
        .when()
            .post("/users")
        .then()
            .statusCode(201)
            .body("name", equalTo("Ravi"))
            .body("id", notNullValue());
    }
}

Tests passed · status 201 Created · id returned

Note: Java 15+ text blocks (""") make multi-line JSON readable. For Java 8, use a concatenated string or a POJO.

Store user-schema.json in src/test/resources and use matchesJsonSchemaInClasspath.

import static io.restassured.RestAssured.*;
import static io.restassured.module.jsv.JsonSchemaValidator.*;

public class SchemaTest {
    public static void main(String[] args) {
        given()
            .baseUri("https://api.example.com")
        .when()
            .get("/users/1")
        .then()
            .statusCode(200)
            .body(matchesJsonSchemaInClasspath("user-schema.json"));
    }
}

Tests passed · response matches user-schema.json