About this lesson
REST Assured DELETE request: check 204 No Content and an empty body
Learn REST AssuredIntermediateDELETE and HTTP Methods
How it works
DELETE asks the server to remove the resource at a URI. When it succeeds and has nothing more to say, the right answer is 204 No Content: a success status with no message body at all. That is what testkru returns for DELETE /users/1. An id outside the five demo users gets 404 with a JSON error instead.
A DELETE carries no payload, so in REST Assured it is the shortest request in the course: given() followed by delete() with the path. The Response still has a status code and headers, and getBody().asString() returns an empty string, which is the simplest way to confirm the server sent nothing back.
Be careful with parsing here. There is no JSON in a 204. jsonPath() itself still returns, but the first value you read from it throws a JsonPathException instead of returning null. Read the status first and parse only when you know a body exists. Note too that the sandbox does not really remove anything: a repeat DELETE is again 204 and a GET still finds John Doe.
About the assignment
Delete user 1 and prove the server answered with a bare success: status 204 and a body that is completely empty.
What you will do
- Send a DELETE to
/users/1withgiven()anddelete(), keeping theResponse. - Write out the status, labelled
Status:. - Turn the body into a string with
getBody().asString()and ask itisEmpty(). - Print that boolean after the label
Body is empty:.
Common mistakes
Asserting 200 for a delete
Some APIs return 200 with a confirmation body, but this one returns 204. Copying
statusCode(200)from an earlier lesson makes a passing delete look like a failure.Parsing the empty body
Reaching for
jsonPath().getString()out of habit fails with aJsonPathException, because there is no document to parse. Check emptiness on the raw string instead.Treating a repeat delete as proof
A real API may answer a second DELETE with 404 or with 204 again. Decide which your contract promises, and confirm removal with a follow-up GET rather than with the delete status alone.
In a real test suite
In a real suite a delete test usually creates its own record first, deletes it, and then asserts that a GET for the same id returns 404. That keeps tests independent of shared seed data and checks the deletion actually took effect.
Related lessons
- OPTIONS RequestAsks the server which methods, DELETE among them,
/userssupports. - HEAD RequestAnother response with no body: a HEAD request that still returns headers.
- Handle 404 Not FoundShows the 404 JSON error an unknown user id produces.
To try one of these calls on any API endpoint without a task, open the Online Selenium Java Compiler (REST Assured is included).
Starter code
The editor above opens with this code. Fill in the TODO lines, then run and submit it.
import io.restassured.RestAssured;
import io.restassured.response.Response;
import io.restassured.specification.RequestSpecification;
import static io.restassured.RestAssured.*;
public class Main {
public static void main(String[] args) {
RestAssured.baseURI = "https://testkru.com/api";
// TODO: DELETE /users/1
// TODO: Print the status code
// TODO: Check if body is empty: response.getBody().asString().isEmpty()
}
}