82 REST Assured interview questions with answers

What they are assessing

Basic orientation.

Model answer

A Java library for testing REST APIs, providing a fluent domain specific language for building requests and validating responses without writing boilerplate HTTP client code. It handles the request construction, serialisation, the call itself and response parsing, and integrates with JUnit or TestNG so API tests sit alongside the rest of a Java suite. It was created to make API testing in Java as concise as it is in dynamic languages, which is why the syntax looks unlike typical Java.

Likely follow-up

What would you be writing instead if you used a plain HTTP client?

What they are assessing

Practical setup.

Model answer

The rest-assured artefact at test scope, plus Hamcrest for matchers, which usually arrives transitively. A JSON binding library such as Jackson or Gson is needed on the classpath for automatic serialisation and deserialisation of objects, and REST Assured picks whichever it finds. json-schema-validator is a separate module required for schema validation, and xml-path and json-path are separate artefacts if you need those APIs directly. Forgetting the binding library is the usual cause of serialisation failing at runtime rather than at compile time.

What they are assessing

Tool positioning.

Model answer

Postman is an application with a graphical interface, good for exploration, manual verification and sharing collections, with scripting in JavaScript. REST Assured is a library used in code, so tests live in version control alongside the application, are reviewed like code, reuse the project model classes, and run natively in the build. The practical division is that Postman is better for investigating an API and REST Assured is better for a maintained regression suite. Newman lets Postman collections run in CI, which narrows the gap but does not remove the code reuse advantage.

What they are assessing

Awareness of the main alternative.

Model answer

Karate is a standalone framework with its own domain specific language, so tests are written in a Gherkin-like syntax rather than Java, which makes it accessible to people who do not write Java and removes a great deal of boilerplate. It also bundles parallel execution, reporting and mocking. REST Assured is a library inside a Java project, which is better when the team already writes Java, when tests need to reuse application classes, or when API tests sit in the same framework as UI tests. Karate is often the faster start, REST Assured the better fit inside an existing Java codebase.

Trap to avoid

Claiming Karate is BDD because it uses Given, When and Then. Like REST Assured, it borrows the vocabulary without the collaborative practice behind it.

What they are assessing

Scope awareness.

Model answer

Primarily, as the name suggests, but it handles any HTTP interaction, so it works for SOAP over HTTP, GraphQL by posting a query in the body, and plain HTTP endpoints. For SOAP the XML support through XmlPath and XPath assertions is adequate though less convenient than a dedicated tool. For GraphQL it works but is awkward, since every call is a POST to one endpoint and the meaningful assertions are all inside the response body, so the DSL adds less value than it does for REST.

What they are assessing

The core syntax, asked in almost every interview.

Model answer

given sets up the request: headers, parameters, body, authentication and cookies. when performs the HTTP call with the method and endpoint, such as get or post. then validates the response: status code, body content, headers and response time. The three read as a sentence, which is why the library is readable. The chain is terminated either by the assertions themselves or by extract when you need a value from the response.

Likely follow-up

Can you omit given entirely?

What they are assessing

A distinction interviewers deliberately probe.

Model answer

No. It borrows the vocabulary because it reads well, but there is no collaborative practice behind it: nobody from the business is reading a REST Assured test, and the structure is arrange, act, assert with different words. BDD is about discovering behaviour through conversation before implementation, and a Java test class using given and when has nothing to do with that. Candidates who claim REST Assured gives them BDD are signalling they have the vocabulary without the practice.

Trap to avoid

Saying the syntax makes it BDD. It is the same borrowing that happens with Karate, and interviewers familiar with BDD will follow up.

What they are assessing

A practical detail that trips beginners.

Model answer

Because the DSL is designed to read as a sentence, and qualifying every call would destroy that. The usual imports are everything from RestAssured for given, when and the configuration entry points, everything from Hamcrest Matchers for equalTo, hasItems and the rest, and the schema validator matchers if used. Missing the Hamcrest static import is the most common setup problem, because the code looks correct and simply does not compile, and the error message points at the matcher rather than the import.

What they are assessing

Where validation ends and data retrieval begins.

Model answer

then performs assertions and returns a ValidatableResponse so more assertions can be chained. extract ends the validation chain and returns data: the whole Response object, a single path value, or a deserialised object. You use extract when a value is needed for a subsequent call or for assertions that the DSL cannot express. Both can appear in the same chain, with assertions first and extract last, which is the usual pattern for chaining requests.

What they are assessing

Basic request construction.

Model answer

queryParam adds a parameter to the query string after the question mark. pathParam substitutes a named placeholder in the URL template, so a path written with a placeholder in braces is filled in. formParam sends a parameter in the body as form encoded data, used with content type application form urlencoded. There is also a generic param method, which decides between query and form based on the HTTP method, and I would avoid it because explicit is clearer.

Likely follow-up

Why is pathParam better than string concatenation in the URL?

What they are assessing

The most common request type.

Model answer

By setting the content type to JSON and passing the body, which can be a string, a Map, or a POJO that REST Assured serialises automatically using whichever binding library is on the classpath. Passing a POJO is usually best, because the object is type checked at compile time and can be reused across tests, whereas a string literal containing JSON is easy to get subtly wrong and no compiler will tell you. Setting the content type matters: without it many APIs reject the request or interpret the body differently.

What they are assessing

A specific request type with its own method.

Model answer

With multiPart, passing a File, or a control name with a file, or a byte array with a filename and content type. REST Assured sets the multipart content type automatically. The details that cause problems are the control name needing to match what the server expects, which is often file but not always, and the content type of the part itself, since an API validating the declared type will reject a correctly uploaded file announced as the wrong type. Several multiPart calls can be chained for multiple files or mixed form fields.

What they are assessing

Routine request configuration.

Model answer

With header or headers for individual values or a map, and cookie or cookies similarly. contentType and accept are convenience methods for the two most common headers. For a header sent on every request, such as a correlation id or an API key, setting it once on a RequestSpecification is better than repeating it, and for something genuinely cross cutting a filter is cleaner still, since it applies without the test needing to know about it.

What they are assessing

The most common real pattern in API suites.

Model answer

By extracting the value from the first response and passing it into the second: extract the identifier with a path expression or by deserialising into an object, then use it as a path parameter or in the body of the next call. The design consideration is that a chained sequence makes tests dependent on each other if the chaining spans test methods, so the setup call should happen within the test or in a helper rather than relying on a previous test having run. For anything used by many tests, a helper that creates the resource and returns its id is cleaner than repeating the chain.

Likely follow-up

How do you avoid the created resources accumulating across runs?

What they are assessing

The simplest validation.

Model answer

With statusCode, passing the expected integer, or statusLine for the full line. There is also a Hamcrest matcher form so you can assert a range, which is occasionally useful. The point worth making alongside it is that a status code assertion alone is a weak test: an API returning 200 with an empty body or an error message in the payload passes, so the status is a precondition rather than the verification.

Trap to avoid

Writing a suite where most tests assert only the status code. It produces high test counts and very little verification.

What they are assessing

Core validation.

Model answer

With body, taking a path expression and a Hamcrest matcher, such as a path to a field and equalTo for its value. Several path and matcher pairs can be supplied to one body call, and several body calls can be chained. For a list you use matchers such as hasItems, hasSize or everyItem. Where the assertion becomes complex, extracting the value and asserting with an assertion library is usually more readable than forcing it into a matcher.

What they are assessing

A readability feature.

Model answer

It sets a prefix applied to subsequent body path expressions, so a series of assertions against nested fields do not each repeat the parent path. It is useful when validating several fields of one nested object, and it can be detached or reset afterwards. The caution is that it introduces state into the chain, so a long sequence with a root path set partway through is harder to read than the repetition it saved, and I would use it only where the repetition is genuinely heavy.

What they are assessing

A feature that is frequently misused.

Model answer

With time, taking a Hamcrest matcher such as lessThan with a duration, optionally with a time unit. It is useful as a coarse guard against a drastic regression. It is not performance testing, and asserting a tight threshold in a functional suite produces intermittent failures on a loaded CI agent, which teaches the team to ignore failures. Real performance work belongs in a load testing tool where the measurement is statistical rather than a single sample.

Likely follow-up

Why is a single response time measurement a poor performance assertion?

What they are assessing

Depth of verification.

Model answer

The response body content against expected values, including that fields which should be absent are absent. The structure, ideally through schema validation so an unexpected type or a missing field fails. Headers that matter, such as content type, caching directives and any security headers. The state change on the server, verified by a subsequent read rather than trusting the response. And for error cases, the error body shape and message, since a consistent error contract is something clients depend on and is routinely untested.

What they are assessing

A detail that surprises people coming from other tools.

Model answer

Groovy GPath, not the Jayway JsonPath syntax used elsewhere. So you write dotted paths and can use Groovy closures for filtering and collection operations, rather than the dollar and bracket notation of JsonPath. This matters because examples found online are frequently for the other syntax and will not work. GPath is more powerful for in-line filtering, since you can express find, findAll, collect and sum directly in the assertion.

Trap to avoid

Pasting a Jayway JsonPath expression into a body assertion. It fails confusingly, and it is one of the most common beginner problems.

What they are assessing

Applying GPath rather than describing it.

Model answer

With a Groovy closure inside the path expression, using findAll with a predicate and then selecting a field, so you can assert that the names of all records matching a condition contain particular values. For a single match, find rather than findAll. For aggregates, collect and sum work in the same position. The alternative, extracting the list and filtering in Java, is more verbose but considerably easier to read when the condition is complex, and I would switch to that once the closure stops being obvious.

What they are assessing

A core operation.

Model answer

With extract and path, giving the GPath expression, which returns the typed value. Or extract and response to get the whole Response object and then query it with jsonPath or xmlPath, which is better when several values are needed since it parses once. Or extract and as with a class to deserialise into an object. For a list, extracting with a path returns a List and the generic type needs care, since REST Assured cannot always infer it.

What they are assessing

Handling both content types.

Model answer

JsonPath parses a JSON response and exposes GPath queries over it; XmlPath does the same for XML and also supports XPath expressions through its own methods. Both can be obtained from an extracted Response, and both are usable standalone on a string, which is useful for parsing a payload that did not come from a REST Assured call. The practical difference is that XML has attributes and namespaces, so XmlPath has extra handling for both, and namespace-aware documents need explicit configuration or queries silently return nothing.

What they are assessing

A high value technique that is underused.

Model answer

Validating the structure of a response against a schema document describing the expected fields, types, required properties and constraints, rather than asserting on individual values. It is valuable because it catches contract changes that value assertions miss: a field changing type from number to string, a required field disappearing, or an unexpected field appearing. One schema assertion covers more than a dozen individual checks and it fails for a reason that is immediately diagnostic.

Likely follow-up

What does schema validation not tell you?

What they are assessing

The mechanics.

Model answer

With the json-schema-validator module added as a dependency, then asserting on the body with matchesJsonSchemaInClasspath and a schema file path, or matchesJsonSchema with a File or a string. The schema is a standard JSON Schema document, usually kept in test resources. The common failure is forgetting the separate dependency, since the matcher does not exist without it, and the second is a schema that is too permissive to catch anything, which happens when it is generated from a sample response without tightening required fields.

What they are assessing

A design question with a meaningful answer.

Model answer

From the API specification, ideally generated from the OpenAPI document that the API publishes, so the schema and the implementation share a source of truth. Generating it from a sample response is the common shortcut and is weaker, because it encodes what the API currently does rather than what it promises, so it will not detect a change that was never agreed. Where the specification exists, validating against it turns the test suite into a contract check, which is a materially stronger position than asserting on example values.

What they are assessing

The POJO mechanism.

Model answer

Automatically, using Jackson, Gson or JAXB depending on what is on the classpath and the content type set on the request. Passing an object to the body method serialises it, so no manual JSON construction is needed. The content type matters, because it determines the mapper chosen, and without it serialisation can fail or produce the wrong format. The mapper can be configured through ObjectMapperConfig when the defaults are unsuitable, such as needing a particular date format or naming strategy.

What they are assessing

The reverse operation.

Model answer

With extract and as, passing the target class, which uses the same mapper machinery. For a generic collection, a TypeRef is needed because Java erases the type parameter, which is a detail that catches people out when extracting a list of objects. Once deserialised, assertions are made in ordinary Java with an assertion library, which is frequently more readable than a long chain of body matchers and gives better failure messages.

Likely follow-up

Why does extracting a List of a custom type need a TypeRef?

What they are assessing

A design trade-off with a defensible answer either way.

Model answer

POJOs for most work, because they are compile time checked, refactorable, reusable, and make building variations of a payload straightforward with a builder. Raw strings have one genuine advantage: they let you send something a POJO cannot express, such as a field of the wrong type or an entirely malformed payload, which is exactly what negative testing requires. So my usual arrangement is POJOs for valid requests and raw strings or maps for the deliberately invalid ones, because testing that the API rejects bad input is a case the typed model will prevent you from writing.

Trap to avoid

Using POJOs exclusively. It quietly removes the ability to test malformed input, which is a large part of API negative testing.

What they are assessing

Breadth.

Model answer

Basic, both challenged and preemptive, digest, form based, OAuth 1 and OAuth 2 through the auth entry point. Bearer tokens are usually handled as an explicit Authorization header rather than through the auth API, which is simpler and clearer. Certificate based authentication is configured through SSLConfig. For anything bespoke, a filter adding the required header is the clean approach, since it applies to every request without each test knowing about it.

What they are assessing

A distinction that causes real failures.

Model answer

Challenged basic waits for the server to respond with a 401 and a challenge, then resends with credentials, so there are two round trips. Preemptive sends the Authorization header on the first request without waiting. Many APIs do not issue a challenge and simply reject the unauthenticated request, so the challenged form fails against them. Preemptive is what you usually want, and defaulting to the non-preemptive form is a common cause of authentication appearing broken when it is configured correctly.

Likely follow-up

What symptom would tell you that you need preemptive rather than challenged?

What they are assessing

A practical problem every real suite faces.

Model answer

By obtaining the token once rather than per test, since the token endpoint is often rate limited and the call is slow. A helper or a filter fetches it, caches it, and refreshes it when it is close to expiry, which matters for long suites where a token obtained at the start expires partway through. The credentials come from the environment or a secret store rather than from the code. For multiple roles, the cache is keyed by role so each test can request the identity it needs without re-authenticating.

What they are assessing

Security testing within an API suite.

Model answer

By calling it as each role and asserting both the permitted and the denied outcomes, because only the negative cases prove the control exists. The specific test that matters most is accessing another user resource by substituting an identifier while authenticated as someone who should not see it, which is broken object level authorisation and the most common serious API finding. It has to be done per endpoint rather than sampled, since one endpoint missing the ownership check is enough. I would also test with no token and with an expired one.

What they are assessing

The main reuse mechanism.

Model answer

A reusable, prebuilt set of request configuration: base URI, base path, headers, content type, authentication and logging, assembled with RequestSpecBuilder and applied to a request with spec. It removes repetition and, more importantly, centralises configuration so changing the base URI or adding a header everywhere is a one line change. Without it, every test carries its own setup and the suite becomes unmaintainable at perhaps fifty tests.

What they are assessing

The counterpart on the validation side.

Model answer

A reusable set of response expectations built with ResponseSpecBuilder, such as the expected status code, content type and any headers that should always be present, applied with spec in the then chain. It is useful for the assertions that apply to every successful response in an API, so individual tests only state what is specific to them. It also makes a cross-cutting requirement enforceable: adding a check for a security header to the shared spec applies it to every test at once.

Likely follow-up

What would you put in a shared ResponseSpecification for an API suite?

What they are assessing

Configuration design.

Model answer

By building the specification from configuration rather than hardcoding it: base URI and any environment specific values read from system properties or a configuration file selected at run time, with a sensible local default. The specification is then constructed once, often in a base class or a static holder, and reused. Credentials come from the environment rather than from any file in the repository. The test of whether this is right is that the same command runs against any environment with only a flag changing.

What they are assessing

Basic diagnostics.

Model answer

With log on either side of the chain: log all in given to print the request, and log all in then to print the response, with finer options for just the body, headers or status. For a suite, logging everything is too noisy, so the better option is log if validation fails on the response and log if validation fails on the request, which produces output only for failing tests. That is the configuration I would set globally rather than per test.

Trap to avoid

Leaving log all enabled across a suite. The output volume makes CI logs unreadable and can leak tokens and personal data into build artefacts.

What they are assessing

The main extension point.

Model answer

An implementation of the Filter interface that intercepts every request and response, able to modify either and to perform side effects before passing control on. Uses include adding an authentication header centrally, injecting a correlation id for tracing, capturing request and response into a report such as Allure, logging selectively, and collecting timing. RequestLoggingFilter and ResponseLoggingFilter are built-in examples. Registering filters globally means tests do not carry cross-cutting concerns, which is what keeps them readable.

What they are assessing

A genuine disclosure risk.

Model answer

By using blacklisted headers, which REST Assured supports through the log configuration so named headers are masked in output, and by not logging everything by default. Beyond headers, a request body containing a password will be printed in full by log all, so a filter that redacts known sensitive fields is worth writing when such payloads exist. This matters because CI logs are widely readable and frequently retained, so a token printed in a build log is a real exposure rather than a theoretical one.

Likely follow-up

Where else besides the console might a logged token end up?

What they are assessing

A very common practical blocker.

Model answer

With relaxed HTTPS validation, either globally on the RestAssured configuration or per request, which disables certificate verification. It is appropriate in a test environment with a self-signed certificate and should never be the default in a configuration that could run against anything real, since it removes the check entirely. The better alternative where it is practical is to add the certificate to a trust store and configure SSLConfig to use it, which keeps verification on.

What they are assessing

A setting that matters more than it appears.

Model answer

Through HttpClientConfig, setting connection and socket timeout parameters on the RestAssured configuration. It matters because the defaults are generous, so a hanging endpoint stalls the suite rather than failing it, and in CI that can mean a build timing out after an hour with no useful output. Setting explicit timeouts converts a hang into a fast, diagnosable failure. The value should be well above normal response time so it does not produce false failures under load.

What they are assessing

The thread safety question, which distinguishes depth.

Model answer

The static fields on RestAssured, such as baseURI, port, authentication and filters, are global mutable state, so they are not safe under parallel execution. A test setting the base URI in its own setup affects every test running concurrently, which produces failures that move around and look like flakiness. The fix is to avoid static configuration in a parallel suite and pass a RequestSpecification explicitly instead, which is local to the request. This is one of the most common causes of a REST Assured suite failing only when parallelism is enabled.

Trap to avoid

Setting RestAssured.baseURI in a BeforeEach. It works serially and breaks silently the moment the suite runs in parallel.

What they are assessing

Design rather than syntax.

Model answer

In layers. A configuration layer reading environment values. A specification layer holding the shared request and response specifications. A service or client layer with one class per API resource exposing meaningful methods such as create customer or fetch order, which encapsulate the endpoint, the payload construction and the call. Model classes for the payloads. Then the tests, which call the service layer and assert, containing no endpoint strings or header setup. The critical property is that an endpoint path appears in exactly one place, so an API change is a single edit.

Likely follow-up

What goes wrong when tests call REST Assured directly?

What they are assessing

A boundary question in framework design.

Model answer

In the test, almost always, because the service layer should be reusable by tests with different expectations, including negative tests expecting a failure. A service method that asserts a 200 internally cannot be used to test the 403 case. The exception is a small number of universal assertions that genuinely always apply, which belong in the shared ResponseSpecification rather than in code. The service layer returns the response and the test decides what is correct.

What they are assessing

A constraint that limits suite reliability.

Model answer

By having each test create what it needs through the API and clean up afterwards, which keeps tests independent and resilient to a shared environment. Unique values are generated rather than hardcoded so parallel runs do not collide. Cleanup in a teardown is the usual mechanism, with the caveat that it does not run if the process is killed, so a periodic purge or a namespacing convention is a necessary backstop. Depending on pre-existing records in an environment is what produces a suite that passes on Monday and fails on Thursday.

What they are assessing

Integration into a broader suite.

Model answer

Well, since both are Java and can share the same build, configuration, reporting and model classes. The most valuable connection is that API calls become the setup mechanism for UI tests: creating a user or an order through the API rather than clicking through the interface removes the largest source of UI test fragility and runtime. Structurally they are usually separate source sets or tagged differently so they can run independently, since the API suite should run in a fraction of the time and be part of the fast feedback loop.

What they are assessing

Pipeline basics.

Model answer

As an ordinary Maven or Gradle test run, since REST Assured is a library executed by JUnit or TestNG. The environment is selected by system property or profile, credentials are injected from the CI secret store as environment variables, and the standard test report XML is published for native result display. Because API tests are fast and need no browser, they are a good candidate to run on every commit rather than on a schedule, which is their main advantage over UI tests in a pipeline.

What they are assessing

Working ahead of implementation.

Model answer

Against a mock or a virtualised service, with WireMock being the common choice in Java, which can be run as a server or in-process and configured to return the agreed responses. That lets tests be written against the contract before the implementation exists, which is useful for parallel development and for exercising error and timeout behaviour the real service will not produce on demand. The risk is drift between the mock and reality, so this needs a contract source such as an OpenAPI document, or a periodic run against the real service.

Likely follow-up

How do you stop the mock drifting from the real API?

What they are assessing

Scaling, with a prerequisite.

Model answer

Yes, since they are fast and IO bound so parallelism gives a large saving. What is needed first is removing the shared state: no static RestAssured configuration, no shared mutable fixtures, unique test data per test rather than fixed identifiers, and no reliance on execution order. The static configuration is the one that catches teams out, because the suite works serially and then fails unpredictably. Once those are addressed, the parallelism is configured in the test framework rather than in REST Assured itself.

What they are assessing

A very common and frustrating situation.

Model answer

Log the actual request and compare it with what Postman sends, which usually answers it immediately. The frequent differences are a missing or wrong content type, Postman adding headers automatically that REST Assured does not, authentication being challenged rather than preemptive, a body serialised differently from the literal string in Postman, and URL encoding of parameters. Postman also follows redirects and manages cookies by default in ways that may differ. Comparing the two raw requests side by side is far faster than reasoning about it.

What they are assessing

Diagnosing extraction failures.

Model answer

The path is wrong, often because the response nests the data under a wrapper the test does not account for. The syntax is Jayway JsonPath rather than GPath, which silently does not match. The response is not JSON at all, such as an HTML error page returned by a proxy, which is why logging the body resolves this quickly. The field is present but named differently due to a serialisation naming strategy. Or the array index assumed does not exist. Printing the response body is the first step in every one of those cases.

What they are assessing

Environment differences.

Model answer

Network reachability first, since the API may be accessible from a developer machine and not from the agent, including proxy configuration which REST Assured needs told about explicitly. Then credentials, which are present locally and may be missing or wrong in the secret store. Then certificates, since a trust store difference produces SSL failures only in CI. Then data, where the local environment has records the CI target does not. Then timing, since a loaded agent exposes races and tight timeouts. Logging on validation failure usually narrows it in one run.

What they are assessing

Flake handling.

Model answer

By capturing enough context to diagnose it after the fact, since reproducing on demand is usually impossible: log request and response on failure, include a correlation id so the server side log can be matched, and record the test data used. Then look at the usual causes in order: shared state between tests, the static configuration problem under parallelism, data created by another test, eventual consistency where a read follows a write too quickly, and genuine race conditions in the service. The eventual consistency case is common and the fix is polling with a timeout rather than a fixed sleep.

Likely follow-up

How would you poll for an eventually consistent result cleanly?

What they are assessing

A method with specific semantics.

Model answer

Mechanically it is the same as PUT with the patch method, but the testing is different because PATCH is a partial update. The cases that matter are that fields not included are left unchanged, which is the defining behaviour and is frequently broken, that including a field with a null value does what the contract says since that is ambiguous in many APIs, and that an unknown field is rejected or ignored according to the contract. Verifying the unchanged fields requires reading the resource afterwards rather than trusting the response.

What they are assessing

Verifying state rather than the response.

Model answer

By reading the resource back, usually from the Location header the response should return, and asserting its content matches what was sent. Trusting the POST response alone is weaker, because an API can return a representation that was never persisted. The additional checks worth making are that the response status is 201 rather than 200, that the Location header is present and resolvable, and that creating the same resource twice behaves according to the contract, whether that is a conflict or a second resource.

What they are assessing

A common API feature with many edge cases.

Model answer

By checking the mechanics and the boundaries. That the page size parameter is honoured, including values above any maximum the API enforces. That the first and last pages behave correctly, with the last page partially filled. That requesting a page beyond the end returns an empty collection rather than an error, or whatever the contract specifies. That total counts are accurate. That ordering is stable, since unstable ordering means an item can appear on two pages or none as you walk through. And that the links or cursors returned actually work when followed.

What they are assessing

Breadth of negative testing.

Model answer

Beyond 200 and 201: 400 for malformed input, 401 for missing or invalid authentication, 403 for authenticated but not permitted, 404 for a resource that does not exist, 405 for a method not allowed on that path, 409 for conflicts such as duplicate creation, 415 for an unsupported content type, and 422 where the API distinguishes semantic validation failure. The error body shape should be asserted alongside the code, since clients depend on a consistent error contract and it is rarely tested.

What they are assessing

Maintainability.

Model answer

A service layer so endpoints and payload construction exist once. Builders or object mothers for test data so a valid payload is created with defaults and tests override only what matters. Shared specifications for request and response configuration. Custom matchers or assertion helpers for domain concepts asserted repeatedly. And filters for anything cross cutting. The outcome to aim for is that a test reads as a sequence of domain actions and assertions, with no HTTP mechanics visible in it at all.

What they are assessing

A routine matcher question.

Model answer

With hasItems, which checks that the listed values are present regardless of order and regardless of extra items, or containsInAnyOrder when the collection must contain exactly those elements. contains requires the exact order. The choice matters: using contains against an API that makes no ordering guarantee produces an intermittently failing test, and using hasItems where exactness matters means an extra unexpected item passes unnoticed.

What they are assessing

A case teams usually skip.

Model answer

With a deliberately expired or malformed token rather than by waiting, asserting the API returns 401 and a clear error rather than a 500 or, worse, processing the request. A token signed with the wrong key, one with an altered payload, and one for a different audience are all worth including, since those test the validation rather than just the expiry timestamp. Where the suite uses token caching, it is also worth testing that the refresh path works, since that code runs rarely and is a common source of long suite failures.

What they are assessing

A practical requirement in corporate environments.

Model answer

With the proxy method on the request or the global proxy configuration, supplying host, port and credentials if required. It is needed when the agent or developer machine routes external traffic through a corporate proxy, which is a frequent cause of tests working in one place and timing out in another. It is also used deliberately to route traffic through a capture tool for debugging, which is a useful technique for comparing what REST Assured actually sends against another client.

What they are assessing

Managing stateful flows.

Model answer

By having each test establish the state it needs through helper methods rather than relying on previous tests, so a test for the final step creates everything leading up to it as setup. That keeps the test independently runnable and parallelisable, at the cost of repeating work, which is usually acceptable because API calls are fast. If the setup is genuinely expensive, the shared fixture is created once per class with the tests reading rather than mutating it. What I would avoid is ordered tests, which are hard to debug and cannot be run individually.

What they are assessing

A frequent source of subtle failures.

Model answer

By configuring the object mapper explicitly rather than relying on the default, since Jackson and Gson serialise dates differently and the default rarely matches an API contract. ObjectMapperConfig allows supplying a configured mapper with the required format and timezone. Timezone is the detail that causes the most trouble, because a test passing locally and failing on a CI agent in a different zone is almost always a date serialised without an explicit zone. Asserting on dates is also better done on a parsed value than on the string.

What they are assessing

Reading a specific error correctly.

Model answer

That the content type sent does not match what the endpoint accepts, and in practice it almost always means the content type was not set at all, so the default was sent or none was. It is one of the most common beginner errors, because the body is correct and the failure appears to be about the payload. The related case is an Accept header mismatch producing a 406, where the server cannot produce the format requested. Logging the request headers resolves both immediately.

What they are assessing

Reporting setup.

Model answer

Through a filter, which is the intended extension point: the filter intercepts request and response and attaches them to the report. Allure provides an AllureRestAssured filter that does exactly this, producing a report where each test shows the full request and response, which is enormously useful for diagnosing a failure without rerunning. Registering it globally means every test gets it. Writing a custom filter is straightforward when the reporting tool has no ready integration.

What they are assessing

Contract verification.

Model answer

With a validator that checks requests and responses against the specification document, such as the swagger-request-validator library, which provides a REST Assured integration so the validation becomes a matcher or a filter applied to every call. That is stronger than hand-written schema assertions because it covers the whole contract including parameters, status codes and response shapes, and because it uses the published specification as the source of truth. It also catches the case where the API is correct and the specification is out of date, which is itself worth knowing.

Likely follow-up

What would you do when the API and the specification disagree?

What they are assessing

A small but real distinction.

Model answer

Simply omitting the body method sends no body, which is correct for GET and DELETE. Sending an explicitly empty body means passing an empty string or an empty JSON object, which are different things to a server: no body, an empty string body, and an empty object are three distinct cases and APIs handle them differently. Testing all three against an endpoint that expects a payload is a worthwhile negative test, since one of them frequently produces a 500 rather than a 400.

What they are assessing

Test placement.

Model answer

API tests verify the contract and the integration: that the endpoint exists, accepts what it says it accepts, returns the documented shape and status, enforces authorisation, and that the operation has the stated effect. Detailed business rule permutations usually belong in unit tests, where they run in milliseconds without a deployed service. The practical consequence is that an API suite should have breadth across endpoints and error cases rather than depth of combinations on one endpoint, and a suite with forty tests for one validation rule has drawn the line in the wrong place.

What they are assessing

Path expression fluency.

Model answer

With a dotted path through the structure, using indices for array elements, and GPath handles the traversal. Where several fields of the same nested object are asserted, rootPath avoids repeating the prefix. Where the structure is deep enough that the path becomes unreadable, deserialising into an object and asserting in Java is clearer and gives better failure messages, which is the point at which I would switch rather than persisting with longer path strings.

What they are assessing

Non-JSON responses.

Model answer

By extracting the response as a byte array or an InputStream rather than attempting to parse it, then asserting on the content type and content disposition headers, the size, and where it matters the actual content by parsing it with an appropriate library. For a PDF or spreadsheet, asserting on bytes is meaningless so a parser is needed to check the content. The headers are often the more important assertion, since a file served with the wrong content type or without a filename is a defect users will notice.

What they are assessing

A genuinely difficult case.

Model answer

By polling with a timeout rather than asserting immediately or inserting a fixed sleep. A fixed sleep is either too short, producing flakiness, or too long, slowing every run. Awaitility is the usual library in Java for this, expressing the condition and the maximum wait declaratively. The polling interval and timeout should be set from the service level expectation rather than guessed. Where the delay is unbounded, that is itself worth raising, since a system with no stated consistency window is difficult for any client to use correctly.

What they are assessing

Session handling.

Model answer

With sessionId on the request, or by capturing cookies from a response and supplying them on subsequent calls, or with a session filter which handles the cookie exchange automatically. For token based APIs the equivalent is holding the token and setting the header. The design point is that the session should be obtained once per suite or per role rather than per test, both for speed and because repeated authentication can trigger rate limiting on the auth endpoint.

What they are assessing

Pipeline design.

Model answer

Deploy, then wait for the service to actually respond rather than sleeping, usually by polling a health endpoint until it returns healthy with a timeout. Then run a short smoke subset to confirm the deployment is viable, which fails fast on a broken deploy. Then the full API suite. Publishing results and failing the build on failure is standard. The health check step is the one most often omitted and the most common cause of a pipeline where the first few tests fail intermittently because the service had not finished starting.

What they are assessing

Negative assertion on structure.

Model answer

By asserting the path is null, which covers an absent field since GPath returns null for a missing path, or more precisely by extracting the response as a map and asserting the key is not present, which distinguishes absent from present-but-null. That distinction matters for APIs where null and omitted mean different things. Schema validation with additionalProperties set to false is the stronger approach when the requirement is that no unexpected fields appear at all.

What they are assessing

Test design judgement.

Model answer

As many as describe one outcome, which for an API response usually means the status, the key fields and the structure, since those together constitute the single thing being verified. What should not happen is a test verifying creation, then update, then deletion, because a failure midway leaves the rest unexecuted and the cause ambiguous. Where several independent properties are being checked, grouping assertions so all failures report together is better than failing at the first, which is one reason to extract and assert with an assertion library rather than chaining matchers.

What they are assessing

Knowing the limits of the tool.

Model answer

No. It is synchronous and blocking, with one thread per request, so generating meaningful load would require an impractical number of threads and the measurement would be distorted by the client. The time assertion is a coarse guard against drastic regression in a functional suite, not a performance measurement. Load testing belongs in a tool designed for it such as JMeter, Gatling or k6, where the client is asynchronous and the results are reported statistically.

Trap to avoid

Proposing a REST Assured suite run with many threads as a load test. The client becomes the bottleneck and the numbers describe the test harness.

What they are assessing

Redirect behaviour.

Model answer

The server is redirecting, and REST Assured follows redirects by default for most methods, so receiving the 302 itself usually means redirect following has been disabled or the redirect is on a method where it is not followed. The common underlying causes are an authentication failure redirecting to a login page, a missing trailing slash, or an HTTP to HTTPS redirect. The redirect configuration lets you disable following, which is the right setting when you want to assert on the redirect itself rather than the destination.

What they are assessing

Balance on a reuse mechanism.

Model answer

Hidden behaviour. A test reading as a simple call may be sending five headers and asserting three things that are nowhere visible in the test file, so a failure points at something the reader cannot see. That is the same objection as a long Cucumber Background or a deep base class. The balance is to put genuinely universal configuration in the shared specification and keep anything a reader would need to know about in the test. A good signal is whether someone unfamiliar could predict what the request contains by reading the test.

What they are assessing

Design from scratch.

Model answer

Start from the contract: if an OpenAPI specification exists, use it for validation so the suite checks the agreement rather than examples. Build the layered structure early, since retrofitting a service layer onto two hundred tests with inline endpoints is expensive. Configuration from the environment from day one, so the suite runs anywhere without edits. Parallel safety from the start, meaning no static configuration, because converting later is a rewrite. And run it in CI from the first week, since a suite that has only ever run on one machine is not a suite.

Likely follow-up

What would you deliberately not build in the first month?

What they are assessing

Handling non-determinism.

Model answer

By asserting on the properties that are invariant rather than on exact values: the structure through schema validation, the types, the presence of required fields, and any constraint the contract guarantees such as ordering or a value range. Fields that genuinely vary, such as generated identifiers and timestamps, are asserted as present and well formed rather than equal to a literal. Attempting to assert exact equality against a response containing a timestamp is the most common way a suite becomes intermittently red for no reason.

What they are assessing

Strategy.

Model answer

By pushing each check to the lowest level that verifies it meaningfully, which usually puts the largest automated layer at API level rather than at the interface. API tests are fast, stable and precise, so they can carry breadth across endpoints, error cases and authorisation. UI tests are reserved for journeys where the interface itself is the risk. In most products that produces a suite that is mostly API with a thin UI layer, and the common failure is the inverse, where everything is tested through the browser because that is where the team started.

What they are assessing

A closing question revealing depth of experience.

Model answer

Tests that assert only the status code. They are quick to write, they produce an impressive test count, and they would pass against an API returning an empty body or the wrong data entirely. Close behind are tests calling REST Assured directly with endpoints and headers inline, so an API change means editing a hundred files, and static configuration that works serially and fails the moment anyone enables parallel execution. All three produce a suite that looks substantial and verifies much less than the team believes.