Introduction

In our previous post, we explored PATCH Requests in REST Assured, learning how to partially update resources. Now, we’ll dive into DELETE Requests, which are used to remove resources from a server. This guide is designed for beginners and experienced developers, providing clear explanations and practical examples to help you master DELETE requests in REST Assured.

Key Point: DELETE requests are used to remove specific resources from an API, such as deleting a user or a post, and are typically simple but require careful validation.

What is a DELETE Request?

A DELETE Request is an HTTP method used to remove a specified resource from the server. For example, sending a DELETE request to /users/1 removes the user with ID 1. DELETE requests are idempotent, meaning multiple identical requests have the same effect as a single request (the resource is deleted once and subsequent requests confirm it’s gone).

In REST Assured, DELETE requests are performed using the delete() method, often with path parameters to identify the resource to delete. Unlike POST or PUT, DELETE requests typically don’t require a request body.

Performing DELETE Requests in REST Assured

Let’s explore how to perform and validate DELETE requests using REST Assured, using the public API https://jsonplaceholder.typicode.com for examples. Note that this API simulates deletions without persisting changes, making it safe for practice.

Option 1: Basic DELETE Request

The simplest DELETE request targets a resource by its ID and validates the response status code. 


import io.restassured.RestAssured;
import org.junit.jupiter.api.Test;
import static io.restassured.RestAssured.*;

public class BasicDeleteTest {

    @Test
    public void testBasicDelete() {
        RestAssured.baseURI = "https://jsonplaceholder.typicode.com";

        given()
            .when()
                .delete("/posts/1")
            .then()
                .statusCode(200);
    }
}

Explanation:

  • delete("/posts/1"): Sends a DELETE request to remove the post with ID 1.
  • then(): Validates the response:
    • statusCode(200): Ensures the deletion was successful. Some APIs return 204 (No Content) for DELETE requests.
  • No request body is needed, as DELETE typically relies on the URL to identify the resource.
Important: Check the API documentation for the expected status code (200 or 204) and whether a request body is required, as some APIs may deviate from standard practices.

Option 2: DELETE Request with Path Parameters

Use path parameters to dynamically specify the resource to delete. 


import io.restassured.RestAssured;
import org.junit.jupiter.api.Test;
import static io.restassured.RestAssured.*;

public class DeleteWithPathParamTest {

    @Test
    public void testDeleteWithPathParam() {
        RestAssured.baseURI = "https://jsonplaceholder.typicode.com";

        given()
            .pathParam("postId", 1)
            .when()
                .delete("/posts/{postId}")
            .then()
                .statusCode(200);
    }
}

Explanation:

  • pathParam("postId", 1): Specifies the post ID in the URL, resulting in /posts/1.
  • delete("/posts/{postId}"): Sends the DELETE request with the dynamic path parameter.

Option 3: DELETE Request with Request Specification

Use a Request Specification to reuse common settings like the base URI or headers for DELETE requests. 


import io.restassured.builder.RequestSpecBuilder;
import io.restassured.specification.RequestSpecification;
import org.junit.jupiter.api.BeforeAll;
import org.junit.jupiter.api.Test;
import static io.restassured.RestAssured.*;

public class DeleteWithSpecTest {

    private static RequestSpecification requestSpec;

    @BeforeAll
    public static void setup() {
        requestSpec = new RequestSpecBuilder()
            .setBaseUri("https://jsonplaceholder.typicode.com")
            .addHeader("Accept", "application/json")
            .build();
    }

    @Test
    public void testDeleteWithSpec() {
        given()
            .spec(requestSpec)
            .pathParam("postId", 1)
            .when()
                .delete("/posts/{postId}")
            .then()
                .statusCode(200);
    }
}

Explanation:

  • RequestSpecBuilder: Defines a reusable specification with the base URI and an Accept header.
  • spec(requestSpec): Applies the specification to the test.
  • pathParam("postId", 1): Adds the dynamic resource ID.
Pro Tip: Use Request Specifications for DELETE requests to centralize common settings, especially when testing multiple endpoints.

Step 1: Validating Deletion

To ensure a resource was deleted, you can follow a DELETE request with a GET request to confirm the resource no longer exists. 


import io.restassured.RestAssured;
import org.junit.jupiter.api.Test;
import static io.restassured.RestAssured.*;

public class ValidateDeleteTest {

    @Test
    public void testValidateDelete() {
        RestAssured.baseURI = "https://jsonplaceholder.typicode.com";

        // Perform DELETE
        given()
            .when()
                .delete("/posts/1")
            .then()
                .statusCode(200);

        // Verify resource is "gone" (simulated in jsonplaceholder)
        given()
            .when()
                .get("/posts/1")
            .then()
                .statusCode(anyOf(equalTo(404), equalTo(200))); // jsonplaceholder doesn't actually delete
    }
}

Explanation:

  • The DELETE request simulates removing the post.
  • The subsequent GET request checks if the resource is gone. Since jsonplaceholder.typicode.com doesn’t persist deletions, it may return 200 with the original resource or 404 in some cases.
  • anyOf(equalTo(404), equalTo(200)): Handles variable API behavior in testing.

Step 2: DELETE Request with Headers

Some APIs require headers (e.g., authentication tokens) for DELETE requests. 


import io.restassured.RestAssured;
import org.junit.jupiter.api.Test;
import static io.restassured.RestAssured.*;

public class DeleteWithHeadersTest {

    @Test
    public void testDeleteWithHeaders() {
        RestAssured.baseURI = "https://jsonplaceholder.typicode.com";

        given()
            .header("Authorization", "Bearer token123")
            .pathParam("postId", 1)
            .when()
                .delete("/posts/{postId}")
            .then()
                .statusCode(200);
    }
}

Explanation:

  • header("Authorization", "Bearer token123"): Adds an authentication header (illustrative, as jsonplaceholder doesn’t require it).
  • Use real API tokens for production APIs requiring authentication.

Step 3: Verify Setup with pom.xml

Ensure your pom.xml includes dependencies for REST Assured and JUnit: 



    
        io.rest-assured
        rest-assured
        5.4.0
        test
    
    
        org.junit.jupiter
        junit-jupiter
        5.10.2
        test
    
    
        org.hamcrest
        hamcrest
        2.2
        test

Run the tests using mvn test or your IDE’s test runner to confirm the setup.

Tips for Beginners

  • Check API Documentation: Verify the endpoint, required headers, and expected status code (200 or 204).
  • Validate Deletion: Follow DELETE with a GET request to confirm the resource is gone (if the API persists changes).
  • Use Public APIs: Practice with jsonplaceholder.typicode.com for safe experimentation.
  • Enable Logging: Use RestAssured.enableLoggingOfRequestAndResponseIfValidationFails() to debug issues.
Troubleshooting Tip: If a DELETE request returns a 404 Not Found or 403 Forbidden error, ensure the resource ID is valid and you have proper authorization (e.g., correct headers or tokens).

What’s Next?

In the next post, we’ll cover Authentication, exploring how to handle various authentication methods (e.g., Basic, OAuth) in REST Assured. Stay tuned for more hands-on examples!