GET Request

A GET request is used to retrieve data from the server. It does not modify or create any data.

In REST Assured, a GET request follows the BDD pattern:

  • given() → Configure request details (headers, query parameters, authentication, etc.)
  • when() → Send the GET request.
  • then() → Validate the response.

Advertisement

GET Request Flow

given()
   │
   ├── Headers
   ├── Query Parameters
   ├── Authentication
   │
   ▼
when()
   │
   └── GET /users/123
   │
   ▼
then()
   │
   ├── Status Code
   ├── Response Body
   ├── Headers
   └── Response Time

REST Assured Example

given()
        .header("Authorization", "Bearer " + token)

.when()
        .get("/users/123")

.then()
        .statusCode(200)
        .body("name", equalTo("John Doe"));

GET Request Characteristics

Feature GET Request
Purpose Retrieve data from the server
Request Body Not Required
Safe Operation Yes
Idempotent Yes
REST Assured Method given().when().get("/endpoint")

Real-Time Example

Retrieve user details:

GET /users/123

Expected Response:

{
   "id":123,
   "name":"John Doe"
}

Interview Answer

"A GET request retrieves data from the server without modifying it. In REST Assured, I configure request details in given(), send the request using .get() in when(), and validate the status code, response body, and headers in then(). GET requests do not require a request body."


POST Request

A POST request is used to create a new resource or submit data to the server.

Examples include:

  • Creating a user
  • Creating an order
  • Adding a product
  • Registering a customer

POST Request Flow

given()
   │
   ├── Headers
   ├── Authentication
   ├── Payload
   │
   ▼
when()
   │
   └── POST /users
   │
   ▼
then()
   │
   ├── Status Code (201)
   ├── Response Body
   └── Headers

Sample Payload

{
  "name":"John",
  "email":"john@test.com"
}

REST Assured Example

given()
        .contentType(ContentType.JSON)
        .body(payload)

.when()
        .post("/users")

.then()
        .statusCode(201);

POST Request Characteristics

Feature POST Request
Purpose Create new resource
Request Body Required
Safe Operation No
Idempotent No
Success Status Code 201 Created

Real-Time Example

We use POST requests to create new users, add products, or submit forms. A successful request returns 201 Created, while invalid input usually returns 400 Bad Request.


Interview Answer

"A POST request sends data to the server to create a new resource. In REST Assured, I set the headers, authentication, and payload in given(), send the request using .post() in when(), and validate the response in then(), typically expecting a 201 Created status code."


PUT Request

A PUT request updates an existing resource by replacing the entire resource with the new data.


PUT Request Flow

given()
   │
   ├── Headers
   ├── Authentication
   ├── Updated Payload
   │
   ▼
when()
   │
   └── PUT /users/123
   │
   ▼
then()
   │
   ├── Status Code (200)
   ├── Updated Response
   └── Headers

REST Assured Example

given()
        .contentType(ContentType.JSON)
        .body(updatedPayload)

.when()
        .put("/users/123")

.then()
        .statusCode(200)
        .body("email", equalTo("john@test.com"));

PUT Request Characteristics

Feature PUT Request
Purpose Replace an existing resource
Request Body Required
Idempotent Yes
Success Status Code 200 OK

Real-Time Example

In my project, I automated the Update User API by sending a PUT request with the updated name and email. I validated the 200 OK status code and confirmed the updated fields in the response.


Interview Answer

"A PUT request replaces an existing resource with new data. In REST Assured, I configure the updated payload in given(), call .put() in when(), and verify the updated resource and status code in then()."


DELETE Request

A DELETE request removes an existing resource from the server.


DELETE Request Flow

given()
   │
   ├── Headers
   ├── Authentication
   ├── Path Parameter
   │
   ▼
when()
   │
   └── DELETE /users/123
   │
   ▼
then()
   │
   ├── Status Code (200 / 204)
   └── Validate Deletion

REST Assured Example

given()
        .spec(authSpec)
        .pathParam("id", userId)
.when()
        .delete("/users/{id}")
.then()
        .statusCode(204);

// Prove it's really gone
given().spec(authSpec).pathParam("id", userId)
.when().get("/users/{id}")
.then().statusCode(404);

A 204 only says the server accepted the request — the follow-up GET proves the resource was deleted. Some APIs return 200 with a body, or (like Restful Booker) 201; assert what the API documents.


DELETE Request Characteristics

Feature DELETE Request
Purpose Delete resource
Request Body Usually Not Required
Idempotent Yes
Success Status Code 200 OK / 204 No Content

Interview Answer

"A DELETE request removes a resource from the server. In REST Assured, I call .delete() in the when() section and validate the expected status code, usually 200 OK or 204 No Content, in the then() section."


PATCH Request

A PATCH request updates only specific fields of an existing resource.

Unlike PUT, PATCH does not replace the entire resource.


PATCH Request Flow

given()
   │
   ├── Headers
   ├── Authentication
   ├── Partial Payload
   │
   ▼
when()
   │
   └── PATCH /users/123
   │
   ▼
then()
   │
   ├── Status Code
   ├── Updated Fields
   └── Response Validation

Sample PATCH Payload

{
   "email":"john@test.com"
}

REST Assured Example

given()
        .contentType(ContentType.JSON)
        .body(patchPayload)

.when()
        .patch("/users/123")

.then()
        .statusCode(200)
        .body("email", equalTo("john@test.com"));

PUT vs PATCH

PUT PATCH
Replaces entire resource Updates only specified fields
Full payload required Partial payload required
Idempotent Not guaranteed — depends on the operation (setting a field is idempotent; "increment" is not)
Larger request body Smaller request body

Real-Time Example

We verified the authentication token, response time, and headers before sending a PATCH request. The payload contained only the field that needed updating, making the request more efficient than a full PUT operation.


Interview Answer

"A PATCH request updates only specific fields of an existing resource. In REST Assured, I send only the fields that need modification in the request body, call .patch() in when(), and validate the updated fields in the response."


Query Parameters

Query parameters are key-value pairs added to the URL to filter, search, sort, or paginate data.

They appear after the ? symbol.


Examples

Filter products:

/products?brand=Dell

Search products:

/products?keyword=Laptop

Pagination:

/products?page=2&size=20

REST Assured Example

Single Query Parameter

given()
        .queryParam("brand", "Dell")

.when()
        .get("/products")

.then()
        .statusCode(200);

Multiple Query Parameters

given()
        .queryParam("brand", "Dell")
        .queryParam("price", 50000)

.when()
        .get("/products");

Uses

  • Filtering
  • Sorting
  • Searching
  • Pagination

Interview Answer

"Query parameters are key-value pairs appended to the URL to filter or customize API responses. In REST Assured, I pass them using .queryParam() or .queryParams() inside the given() section."


Path Parameters

Path parameters are dynamic values embedded directly in the URL that identify a specific resource.

Example:

/users/123

Here,

123

is the path parameter.


REST Assured Example

given()
        .pathParam("id", 123)

.when()
        .get("/users/{id}")

.then()
        .statusCode(200);

Uses

  • Retrieve a specific resource
  • Update a resource
  • Delete a resource

Interview Answer

"Path parameters are dynamic values in the URL used to identify a specific resource. In REST Assured, I pass them using .pathParam() or .pathParams() before sending the request."


Headers

Headers are key-value pairs sent along with the request to provide additional information.

Common request headers include:

  • Content-Type
  • Authorization
  • Accept
  • User-Agent

Single Header

given()
        .header("Content-Type", "application/json");

Multiple Headers

given()
        .headers(
                "Content-Type", "application/json",
                "Authorization", "Bearer " + token
        );

Headers Using a Map

Map<String, String> headers = new HashMap<>();

headers.put("Content-Type", "application/json");
headers.put("Authorization", "Bearer " + token);

given()
        .headers(headers);

Validating Response Headers

response.then()
        .header("Content-Type", containsString("application/json"))   // servers often add "; charset=utf-8"
        .header("Location", matchesPattern(".*/users/\\d+$"));          // after a POST that creates a resource

An exact match on application/json fails when the server appends a charset — use containsString or .contentType(ContentType.JSON).


Common Headers

Header Purpose
Content-Type Specifies request/response data format
Authorization Authentication token
Accept Expected response format
User-Agent Client information

Real-Time Example

In my project, I used Content-Type: application/json for POST and PUT requests, passed Authorization: Bearer <token> for secured APIs, and validated response headers such as Content-Type and Server.


Interview Answer

"Headers are key-value pairs that provide metadata about the request or response. In REST Assured, I use .header() for a single header, .headers() for multiple headers, or pass a Map<String, String> for reusable header collections."


Cookies

Cookies are small pieces of data used to maintain session information between the client and server.

Some applications use cookies instead of bearer tokens for authentication.


REST Assured Example

given()
        .cookie("JSESSIONID", "ABC123XYZ")

.when()
        .get("/profile")

.then()
        .statusCode(200);

Multiple Cookies

given()
        .cookies(
                "JSESSIONID", "ABC123XYZ",
                "USER", "John"
        );

Validate Cookies

response.then()
        .cookie("JSESSIONID");

When Are Cookies Used?

Cookies are commonly used for:

  • Session Management
  • Login Sessions
  • Authentication
  • User Preferences

Interview Answer

"Cookies are small pieces of data used to maintain session state between the client and server. In REST Assured, I pass cookies using .cookie() or .cookies() when APIs rely on session-based authentication instead of bearer tokens."


Best Practices

  • Use GET only for retrieving data.
  • Use POST to create resources.
  • Use PUT for complete resource replacement.
  • Use PATCH for partial updates.
  • Use DELETE to remove resources.
  • Pass query parameters for filtering and pagination.
  • Use path parameters to identify specific resources.
  • Always send the correct Content-Type and Authorization headers.
  • Validate response headers, cookies, and status codes.

📚 Official documentation: REST Assured official site · MDN: HTTP

Frequently Asked Questions (FAQs)

1. How do you send a GET request in REST Assured?

Use:

given()
.when()
.get("/endpoint")
.then();

Configure headers, query parameters, or authentication in given(), call .get() in when(), and validate the response in then(). GET requests do not require a request body.


2. How do you send a POST request?

Configure headers, authentication, and the request body in given(), send the request using .post("/endpoint") in when(), and validate the response (typically 201 Created) in then().


3. What is the difference between PUT and PATCH in REST Assured?

  • PUT replaces the entire resource and requires the complete payload.
  • PATCH updates only specific fields and requires only the fields that need to be changed.

4. How do you pass query parameters?

Use .queryParam() for a single parameter or .queryParams() for multiple parameters inside the given() section.


5. How do you pass path parameters?

Use .pathParam() or .pathParams() inside the given() section to provide dynamic values in the endpoint URL, such as a user ID.


6. How do you set headers?

REST Assured provides:

  • .header() for a single header
  • .headers() for multiple headers
  • .headers(Map<String, String>) for reusable header collections

Common headers include Content-Type, Authorization, and Accept.


7. How do you pass cookies?

Use .cookie() for a single cookie or .cookies() for multiple cookies in the given() section. Cookies are typically used to maintain authenticated sessions when the application relies on session-based authentication instead of bearer tokens.


All Five Methods in One Flow

String id = given().spec(authSpec).body(Map.of("name", "John", "email", "john@test.com"))
    .when().post("/users")
    .then().statusCode(201).extract().path("id");                                  // create

given().spec(authSpec).pathParam("id", id)
    .when().get("/users/{id}")
    .then().statusCode(200).body("email", equalTo("john@test.com"));               // read

given().spec(authSpec).pathParam("id", id).body(Map.of("name", "John", "email", "john.d@test.com"))
    .when().put("/users/{id}")
    .then().statusCode(200).body("email", equalTo("john.d@test.com"));             // replace

given().spec(authSpec).pathParam("id", id).body(Map.of("name", "Johnny"))
    .when().patch("/users/{id}")
    .then().statusCode(200).body("name", equalTo("Johnny"))
        .body("email", equalTo("john.d@test.com"));                                // partial update kept the email

given().spec(authSpec).pathParam("id", id).when().delete("/users/{id}").then().statusCode(204);
given().spec(authSpec).pathParam("id", id).when().get("/users/{id}").then().statusCode(404);   // gone

Each step checks its own result, and the PATCH step proves the fields it didn't send were left alone — the key difference from PUT. More: PUT vs PATCH. Watch each request go through given(), when() and then() in the REST Assured Visualizer.

From Real Projects

I've tested APIs at the level of CRUD operations, HTTP methods and JSON path validation, and written automation in Java with TestNG. REST Assured brings those together in one Java library — which is why testers with Selenium and TestNG experience usually pick it up quickly. Start with one resource and automate its full CRUD cycle. Testsigma supports web, mobile and API test automation, so understanding APIs was part of understanding the product I was testing. Log the full request when a call fails — the problem is often in the headers.