Q22 of 40 · REST Assured
How would you debug a test where a real cURL works but REST Assured fails?
REST AssuredMidrest-assureddebuggingcurltroubleshootingapi-testing
Short answer
Short answer: Enable .log().all() on both given() and then() to see the exact request REST Assured sends. Compare URI, headers, body, and content-type encoding to the working cURL. Common culprits: missing content-type, charset differences, basic-auth scheme (non-preemptive vs preemptive), proxy settings cURL uses that REST Assured doesn't.
Detail
The first step is always to make REST Assured's outgoing request fully visible:
given()
.log().all() // prints method, URI, headers, body
.when()
.get("/endpoint")
.then()
.log().all() // prints status, headers, response body
Common root causes:
- Content-Type mismatch — cURL sends
Content-Type: application/json; REST Assured sendsapplication/json; charset=UTF-8(some servers reject the charset suffix). - Auth scheme — non-preemptive basic auth waits for a 401 challenge; cURL sends the header upfront. Fix:
.auth().preemptive().basic(). - Body encoding — cURL sends a raw string; REST Assured serialises a POJO. Check if the resulting JSON field names match (camelCase vs snake_case, Jackson annotations).
- Proxy — cURL on Linux picks up
http_proxyenv var; REST Assured ignores it unless configured:.proxy(host, port)in given(). - TLS — cURL with
-kdisables cert check; REST Assured validates by default. Fix:.relaxedHTTPSValidation(). - Host/port — baseURI in REST Assured vs the URL in cURL — verify they match exactly, including http vs https.
// EXAMPLE
// Step 1: log everything to compare with cURL
given()
.log().all()
.baseUri("https://api.example.com")
.contentType("application/json") // try without charset if server rejects
.header("Authorization", "Bearer " + token)
.body("{ \"name\": \"Alice\" }")
.when()
.post("/users")
.then()
.log().all()
.statusCode(201);
// cURL equivalent to compare:
// curl -v -X POST https://api.example.com/users \
// -H "Content-Type: application/json" \
// -H "Authorization: Bearer <token>" \
// -d '{"name":"Alice"}'// WHAT INTERVIEWERS LOOK FOR
Systematic debugging approach (log first, compare second), knowledge of the common mismatches (charset, auth preemptive, proxy), and the ability to correlate REST Assured output to cURL flags. This is a practical question that separates experienced users from those with only tutorial experience.
// COMMON PITFALL
Changing REST Assured config randomly without first logging the actual request. Without seeing what REST Assured actually sends, you're guessing — .log().all() should always be the first debugging step.