Why Returning different status codes in Spring Boot? - Purpose & Use Cases

The Big Idea

Discover how a simple change can make your web service speak clearly to every user and system.

The Scenario

Imagine building a web service where you must tell users if their request succeeded, failed, or if something went wrong. You try to do this by writing many if-else checks and printing messages manually.

The Problem

Manually managing status codes is confusing and error-prone. You might forget to send the right code, causing clients to misunderstand the response. It's hard to keep track of all possible outcomes and update them consistently.

The Solution

Spring Boot lets you return different HTTP status codes easily by using built-in annotations and response objects. This makes your code cleaner and ensures clients get clear, correct signals about what happened.

Before vs After

✗ Before

if (error) { return "Error happened"; } else { return "Success"; }

✓ After

@GetMapping
public ResponseEntity<String> get() {
  if (error) {
    return ResponseEntity.status(HttpStatus.BAD_REQUEST).body("Error happened");
  }
  return ResponseEntity.ok("Success");
}

What It Enables

You can clearly communicate success, failure, or other states to users and systems, making your API reliable and easy to use.

Real Life Example

When a user submits a form, your service can return 200 OK if all is good, 400 Bad Request if data is missing, or 500 Internal Server Error if something unexpected happens.

Key Takeaways

Manual status handling is confusing and risky.

Spring Boot simplifies returning correct HTTP codes.

Clear status codes improve communication with clients.

Practice

1. In Spring Boot, which class is commonly used to return different HTTP status codes from a controller?

easy

A. ResponseEntity

B. HttpStatusCode

C. HttpResponse

D. StatusCode

Solution

1. Step 1: Understand the purpose of ResponseEntity

   ResponseEntity is a Spring class that allows you to control the HTTP status code, headers, and body of the response.

2. Step 2: Identify the correct class for status codes

   HttpStatusCode, HttpResponse, and StatusCode are not standard Spring Boot classes for returning responses with status codes.

3. Final Answer:

   ResponseEntity -> Option A

4. Quick Check:

   Use ResponseEntity to return status codes [OK]

Hint: Use ResponseEntity to set status codes easily [OK]

Common Mistakes:

• Confusing ResponseEntity with HttpStatusCode
• Trying to return status codes without ResponseEntity
• Using non-existent classes like HttpResponse

2. Which of the following is the correct way to return a 404 Not Found status with a message in a Spring Boot controller?

easy

A. return new ResponseEntity("Not Found", 404);

B. return new ResponseEntity<>("Not Found", 404);

C. return ResponseEntity.status(404).body("Not Found");

D. return ResponseEntity(HttpStatus.NOT_FOUND, "Not Found");

Solution

1. Step 1: Check the syntax for ResponseEntity with status and body

   The method ResponseEntity.status(404).body("Not Found") correctly sets the status and body.

2. Step 2: Identify incorrect syntax options

   B uses a constructor with an int 404 instead of HttpStatus.NOT_FOUND. C uses an int instead of HttpStatus enum. D is not a valid constructor call.

3. Final Answer:

   return ResponseEntity.status(404).body("Not Found"); -> Option C

4. Quick Check:

   Use ResponseEntity.status().body() for custom status [OK]

Hint: Use ResponseEntity.status(code).body(message) [OK]

Common Mistakes:

• Using int instead of HttpStatus enum
• Incorrect constructor usage
• Missing method chaining for status and body

3. What will be the HTTP status code returned by this Spring Boot controller method?

public ResponseEntity<String> getUser(boolean found) {
    if (found) {
        return ResponseEntity.ok("User found");
    } else {
        return ResponseEntity.status(HttpStatus.NOT_FOUND).body("User not found");
    }
}

medium

A. 404 if found is true, 200 if false

B. Always 404

C. Always 200

D. 200 if found is true, 404 if false

Solution

1. Step 1: Analyze the if condition

   If found is true, the method returns ResponseEntity.ok("User found"), which means HTTP 200.

2. Step 2: Analyze the else condition

   If found is false, it returns ResponseEntity.status(HttpStatus.NOT_FOUND).body("User not found"), which means HTTP 404.

3. Final Answer:

   200 if found is true, 404 if false -> Option D

4. Quick Check:

   ResponseEntity.ok = 200, status(HttpStatus.NOT_FOUND) = 404 [OK]

Hint: ResponseEntity.ok = 200, status(HttpStatus.NOT_FOUND) = 404 [OK]

Common Mistakes:

• Mixing up true/false branches
• Assuming default status 200 always
• Confusing status codes with messages

4. Identify the error in this Spring Boot controller method that tries to return a 201 Created status:

public ResponseEntity<String> createItem() {
    return new ResponseEntity<>("Item created", 201);
}

medium

A. Cannot return ResponseEntity with a String body

B. Using int 201 instead of HttpStatus enum

C. ResponseEntity constructor requires three arguments

D. Missing @ResponseBody annotation

Solution

1. Step 1: Check ResponseEntity constructor parameters

   The constructor expects a body and an HttpStatus enum, not an int.

2. Step 2: Identify the incorrect use of status code

   Passing 201 as int causes a compilation error; should use HttpStatus.CREATED instead.

3. Final Answer:

   Using int 201 instead of HttpStatus enum -> Option B

4. Quick Check:

   Use HttpStatus.CREATED, not int 201 [OK]

Hint: Use HttpStatus enum, not int, for status codes [OK]

Common Mistakes:

• Passing int instead of HttpStatus enum
• Forgetting to import HttpStatus
• Assuming String body is invalid

5. You want to create a Spring Boot controller method that returns 201 Created when a new user is successfully added, 400 Bad Request if the input is invalid, and 401 Unauthorized if the user is not logged in. Which code snippet correctly implements this behavior?

hard

A. public ResponseEntity<String> addUser(boolean validInput, boolean loggedIn) {
if (!loggedIn) {
return ResponseEntity.status(HttpStatus.UNAUTHORIZED).body("Unauthorized");
}
if (!validInput) {
return ResponseEntity.status(HttpStatus.BAD_REQUEST).body("Invalid input");
}
return ResponseEntity.status(HttpStatus.CREATED).body("User created");
}

B. public ResponseEntity<String> addUser(boolean validInput, boolean loggedIn) {
if (!validInput) {
return ResponseEntity.status(HttpStatus.UNAUTHORIZED).body("Unauthorized");
}
if (!loggedIn) {
return ResponseEntity.status(HttpStatus.BAD_REQUEST).body("Invalid input");
}
return ResponseEntity.status(HttpStatus.CREATED).body("User created");
}

C. public ResponseEntity<String> addUser(boolean validInput, boolean loggedIn) {
if (!loggedIn) {
return new ResponseEntity<>("Unauthorized", 401);
}
if (!validInput) {
return new ResponseEntity<>("Invalid input", 400);
}
return new ResponseEntity<>("User created", 201);
}

D. }
;)102 ,"detaerc resU"(>gnirtS

Solution

1. Step 1: Verify correct use of HttpStatus enums

   public ResponseEntity<String> addUser(boolean validInput, boolean loggedIn) { if (!loggedIn) { return ResponseEntity.status(HttpStatus.UNAUTHORIZED).body("Unauthorized"); } if (!validInput) { return ResponseEntity.status(HttpStatus.BAD_REQUEST).body("Invalid input"); } return ResponseEntity.status(HttpStatus.CREATED).body("User created"); } uses HttpStatus.UNAUTHORIZED, HttpStatus.BAD_REQUEST, and HttpStatus.CREATED enums correctly.

2. Step 2: Check logical order and syntax

   This code checks !loggedIn first, then !validInput, then returns 201. Options B, C, and D misuse status codes or pass ints to constructors instead of using HttpStatus enums.

3. Final Answer:

   Uses HttpStatus enums with correct logic: !loggedIn (401), !validInput (400), then 201 -> Option A

4. Quick Check:

   Use HttpStatus enums and correct logic order [OK]

Hint: Check login first, then input, use HttpStatus enums [OK]

Common Mistakes:

• Passing int status codes instead of HttpStatus enums
• Mixing up 400 and 401 status codes
• Incorrect order of condition checks