What's Really Happening with REST Assured Right Now
REST Assured remains the default API automation library in Java shops, and Java shops are exactly where the stable, well-paid enterprise QA jobs sit. The shift is in how it is used: it has largely stopped being a standalone API testing tool and become one layer of a combined suite, sitting alongside UI tests and, increasingly, doing setup and teardown for them. Interviewers now ask how you use it to seed state for a UI test far more than they ask about its fluent syntax.
What we'd actually recommend
Wrap it. The raw given/when/then chain is lovely in a demo and unmaintainable at a hundred tests. Build a thin request-specification layer for base URI, auth, logging, and common headers, keep payloads in POJOs or serialisation classes rather than inline JSON strings, and deserialise responses into typed objects so your assertions are compile-checked. Then add JSON schema validation to every endpoint you own. That combination — spec reuse, typed payloads, schema validation — is precisely what a senior reviewer looks for when they read your sample repository.
The pitfall: asserting on JSON paths one field at a time
The most common weak pattern is a wall of `body("data.user.email", equalTo(...))` assertions, one per field. It is verbose, it breaks noisily on harmless changes, and crucially it does not detect a field being removed or a type changing — the exact regressions API tests exist to catch. Schema validation catches those in one line. When a candidate's sample code is nothing but hardcoded JSON-path assertions, it reliably signals that they learned the tool from tutorials rather than from maintaining a suite through a breaking API change.