Problem Details for standard error format in Spring Boot - Step-by-Step Execution

Concept Flow - Problem Details for standard error format

Client sends request

↓

Server processes request

↓

Error occurs?

No→Send normal response

Yes↓

Create Problem Details object

↓

Fill fields: type, title, status, detail, instance

↓

Send Problem Details JSON as error response

↓

Client receives standardized error info

This flow shows how a Spring Boot server handles errors by sending a standardized Problem Details JSON response to the client.

Execution Sample

Spring Boot

import org.springframework.http.HttpStatus;
import org.springframework.http.ProblemDetail;
import org.springframework.http.ResponseEntity;

ProblemDetail pd = ProblemDetail.forStatus(HttpStatus.NOT_FOUND);
pd.setDetail("User with ID 123 not found.");
return ResponseEntity.status(pd.getStatus()).body(pd);

This code creates a Problem Details object for a 404 error with a custom detail message and returns it as the HTTP response body.

Execution Table

Step	Action	ProblemDetail Fields Set	HTTP Status	Response Sent
1	Receive client request	{}	N/A	No response yet
2	Process request	{}	N/A	No response yet
3	Detect resource missing	{}	N/A	No response yet
4	Create ProblemDetail object	{"type": "about:blank", "title": "Not Found", "status": 404}	404	No response yet
5	Set detail message	{"type": "about:blank", "title": "Not Found", "status": 404, "detail": "User with ID 123 not found."}	404	No response yet
6	Send response with ProblemDetail JSON	{"type": "about:blank", "title": "Not Found", "status": 404, "detail": "User with ID 123 not found."}	404	Problem Details JSON sent

💡 Response sent with Problem Details JSON and HTTP status 404

Variable Tracker

Variable	Start	After Step 4	After Step 5	Final
pd	null	{"type": "about:blank", "title": "Not Found", "status": 404}	{"type": "about:blank", "title": "Not Found", "status": 404, "detail": "User with ID 123 not found."}	{"type": "about:blank", "title": "Not Found", "status": 404, "detail": "User with ID 123 not found."}

Key Moments - 2 Insights

Why do we use ProblemDetail.forStatus(HttpStatus.NOT_FOUND) instead of creating ProblemDetail manually?

Using forStatus() sets standard fields like type, title, and status automatically, ensuring consistency as shown in execution_table step 4.

What happens if we don't set the detail field?

The ProblemDetail will still be valid but less informative; detail is optional but recommended for clarity, as seen in step 5 where detail is added.

Visual Quiz - 3 Questions

Look at the execution_table at step 5, what field is added to the ProblemDetail object?

A detail

B status

C type

D title

💡 Hint

Check the 'ProblemDetail Fields Set' column at step 5 in the execution_table.

At which step is the HTTP status code set in the ProblemDetail object?

A Step 3

B Step 5

C Step 4

D Step 6

💡 Hint

Look at the 'HTTP Status' column in the execution_table to see when status becomes 404.

If the server did not detect an error, what would happen according to the concept_flow?

A Send Problem Details JSON anyway

B Send normal response

C Create ProblemDetail object but do not send

D Return empty response

💡 Hint

Refer to the decision branch 'Error occurs?--No--> Send normal response' in the concept_flow.

Concept Snapshot

Problem Details standardizes error responses in JSON.
Use ProblemDetail.forStatus() to create error info.
Set fields: type, title, status, detail, instance.
Return ProblemDetail as HTTP response body.
Clients get consistent, clear error messages.

Full Transcript

When a client sends a request to a Spring Boot server, the server processes it. If an error occurs, such as a missing resource, the server creates a ProblemDetail object using ProblemDetail.forStatus() which sets standard fields like type, title, and status. Then, it adds a detail message explaining the error. Finally, the server sends this ProblemDetail JSON as the error response with the appropriate HTTP status code. This standard format helps clients understand errors clearly and consistently.

Practice

1. What is the main purpose of using Problem Details in Spring Boot APIs?

easy

A. To standardize error messages for better clarity and consistency

B. To speed up API response times

C. To encrypt API responses for security

D. To generate API documentation automatically

Solution

1. Step 1: Understand the role of Problem Details

   Problem Details format is designed to provide a consistent structure for error messages in APIs.

2. Step 2: Identify the main benefit

   This standardization helps clients understand errors clearly and handle them properly.

3. Final Answer:

   To standardize error messages for better clarity and consistency -> Option A

4. Quick Check:

   Standard error format = clarity [OK]

Hint: Problem Details = clear, consistent error messages [OK]

Common Mistakes:

• Thinking it improves speed
• Confusing with security features
• Assuming it auto-generates docs

2. Which of the following fields is NOT part of the standard Problem Details JSON format?

easy

A. type

B. title

C. timestamp

D. status

Solution

1. Step 1: Recall standard Problem Details fields

   The standard fields include type, title, status, detail, and instance.

2. Step 2: Identify the incorrect field

   Timestamp is not part of the official Problem Details specification.

3. Final Answer:

   timestamp -> Option C

4. Quick Check:

   Standard fields exclude timestamp [OK]

Hint: Remember standard fields: type, title, status, detail, instance [OK]

Common Mistakes:

• Confusing timestamp with instance
• Assuming all error info fields are standard
• Mixing with custom fields

3. Given this Spring Boot controller snippet, what will be the HTTP status code in the Problem Details response when ResourceNotFoundException is thrown?

@RestController
public class MyController {
  @GetMapping("/item/{id}")
  public Item getItem(@PathVariable String id) {
    throw new ResourceNotFoundException("Item not found");
  }
}

medium

A. 404 Not Found

B. 200 OK

C. 500 Internal Server Error

D. 400 Bad Request

Solution

1. Step 1: Understand exception mapping in Spring Boot

   ResourceNotFoundException typically maps to HTTP 404 status to indicate missing resource.

2. Step 2: Confirm standard error status for not found

   Spring Boot's default error handling returns 404 for resource not found exceptions.

3. Final Answer:

   404 Not Found -> Option A

4. Quick Check:

   Resource missing = 404 [OK]

Hint: Resource not found usually means 404 status [OK]

Common Mistakes:

• Assuming 200 OK on exception
• Confusing 400 with 404
• Thinking all exceptions return 500

4. You wrote a custom exception handler to return Problem Details but the API returns a plain error message instead. What is the most likely cause?

medium

A. The exception class does not extend RuntimeException

B. The controller method is not annotated with @GetMapping

C. The application.properties file is missing

D. The handler method is missing @ExceptionHandler annotation

Solution

1. Step 1: Check exception handler setup

   Custom handlers must use @ExceptionHandler to catch exceptions and format responses.

2. Step 2: Identify missing annotation impact

   Without @ExceptionHandler, Spring Boot won't invoke the handler, so default error response is sent.

3. Final Answer:

   The handler method is missing @ExceptionHandler annotation -> Option D

4. Quick Check:

   @ExceptionHandler missing = no custom error [OK]

Hint: Always add @ExceptionHandler to custom error methods [OK]

Common Mistakes:

• Thinking controller mapping affects exception handling
• Assuming properties file controls error format
• Believing exception must extend RuntimeException

5. How can you customize the type field in a Problem Details response for a specific exception in Spring Boot?

hard

A. Override the toString() method of the exception class

B. Create a @ControllerAdvice with @ExceptionHandler and build a ProblemDetail with custom type URI

C. Set a property in application.properties named error.type.custom

D. Add a @RequestMapping with produces = "application/problem+json" on the controller

Solution

1. Step 1: Use @ControllerAdvice and @ExceptionHandler

   To customize error details, define a global handler that catches the exception.

2. Step 2: Build ProblemDetail with custom type URI

   Inside the handler, create a ProblemDetail object and set the type field to a custom URI describing the error.

3. Final Answer:

   Create a @ControllerAdvice with @ExceptionHandler and build a ProblemDetail with custom type URI -> Option B

4. Quick Check:

   Custom type = @ExceptionHandler + ProblemDetail [OK]

Hint: Use @ExceptionHandler to customize ProblemDetail fields [OK]

Common Mistakes:

• Trying to override toString() for error format
• Expecting properties file to set type field
• Using @RequestMapping alone to customize error