DTO validation in Spring Boot - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ component_behavior

intermediate

What happens when a DTO field annotated with @NotNull is null?

Consider a Spring Boot REST controller receiving a DTO with a field annotated as @NotNull. What is the expected behavior if the client sends a null value for that field?

Spring Boot

public class UserDTO {
    @NotNull
    private String username;

    // getters and setters
}

@PostMapping("/users")
public ResponseEntity<String> createUser(@Valid @RequestBody UserDTO userDTO) {
    return ResponseEntity.ok("User created");
}

A The controller method executes normally and creates the user with a null username.

B The request is rejected with a 400 Bad Request and a validation error message.

C The application throws a NullPointerException at runtime.

D The server responds with 500 Internal Server Error due to validation failure.

💡 Hint

Think about how Spring Boot handles validation annotations with @Valid.

When a DTO field is annotated with @NotNull and the client sends null, Spring Boot's validation mechanism triggers a validation error. This causes the framework to return a 400 Bad Request response with details about the validation failure.

📝 Syntax

intermediate

Which DTO field annotation correctly validates a string length between 5 and 10?

You want to ensure a DTO string field has a length of at least 5 and at most 10 characters. Which annotation is correct?

Spring Boot

public class ProductDTO {
    // field here
    @Size(min = 5, max = 10)
    private String code;

    // getters and setters
}

A

@Size(min = 5)
private String code;

B

@Length(min = 5, max = 10)
private String code;

C

@Range(min = 5, max = 10)
private String code;

D

@Size(min = 5, max = 10)
private String code;

💡 Hint

Look for the standard javax.validation annotation for string length.

The @Size annotation from javax.validation.constraints is used to validate the length of strings, collections, or arrays. It requires both min and max attributes to set length boundaries.

🔧 Debug

advanced

Why does this DTO validation not trigger an error for an empty string?

Given this DTO field annotated with @NotNull, why does sending an empty string not cause a validation error?

Spring Boot

public class LoginDTO {
    @NotNull
    private String password;

    // getters and setters
}

A @NotNull only checks for null, not empty strings, so empty string passes validation.

B Empty strings are treated as null by default, so validation should fail but does not due to a bug.

C @NotNull also checks for empty strings, so this behavior is unexpected and indicates misconfiguration.

D The validation is skipped because the field is private and lacks a public setter.

💡 Hint

Consider what @NotNull actually validates.

The @NotNull annotation only ensures the value is not null. It does not check if a string is empty. To validate non-empty strings, @NotBlank or @NotEmpty should be used.

❓ state_output

advanced

What is the validation error message when a @Min(18) annotated field is 16?

A DTO has an integer field annotated with @Min(18). If the client sends 16, what validation error message is generated by default?

Spring Boot

public class AgeDTO {
    @Min(18)
    private int age;

    // getters and setters
}

A must be greater than or equal to 18

B value 16 is invalid

C age must be at least 18 years old

D minimum value violation

💡 Hint

Look at the default message for @Min in javax.validation.

The default message for @Min is must be greater than or equal to {value}. So for 18, it becomes must be greater than or equal to 18.

🧠 Conceptual

expert

Why use a separate DTO class with validation instead of validating entity classes directly?

In Spring Boot applications, why is it recommended to create separate DTO classes with validation annotations instead of applying validation directly on JPA entity classes?

A Validation on entities causes database schema errors, so DTOs are safer.

B Entity classes cannot have annotations, so validation must be on DTOs.

C DTOs separate concerns, avoid exposing internal entity structure, and allow tailored validation rules per use case.

D DTOs automatically validate without needing @Valid, unlike entities.

💡 Hint

Think about design principles and security.

Using DTOs for validation helps keep the internal entity model separate from external input. It allows different validation rules for different API endpoints and prevents exposing sensitive or unnecessary entity details.

Practice

1. What is the main purpose of using DTO validation in a Spring Boot application?

easy

A. To handle user authentication and login

B. To speed up database queries automatically

C. To generate HTML pages from data

D. To check and ensure input data meets rules before processing

Solution

1. Step 1: Understand DTO role

   A DTO (Data Transfer Object) carries data between processes and needs validation to ensure data is correct.

2. Step 2: Purpose of validation

   Validation checks input data early to prevent bad data from reaching business logic or database.

3. Final Answer:

   To check and ensure input data meets rules before processing -> Option D

4. Quick Check:

   DTO validation = input data check [OK]

Hint: Validation means checking input data early [OK]

Common Mistakes:

• Confusing validation with database optimization
• Thinking validation generates UI
• Mixing validation with authentication

2. Which annotation is used on a DTO field to require that it must not be empty or null?

easy

A. @Size(min = 1)

B. @NotEmpty

C. @NotNull

D. @Valid

Solution

1. Step 1: Understand annotations meaning

   @NotNull only checks for null, but allows empty strings. @NotEmpty checks for both null and empty strings.

2. Step 2: Choose correct annotation

   To ensure a field is neither null nor empty, @NotEmpty is the best choice.

3. Final Answer:

   @NotEmpty -> Option B

4. Quick Check:

   @NotEmpty = no null or empty [OK]

Hint: Use @NotEmpty to block null and empty strings [OK]

Common Mistakes:

• Using @NotNull but allowing empty strings
• Confusing @Valid with field validation
• Using @Size without min value

3. Given this DTO class snippet:

public class UserDTO {
  @NotNull
  private String username;

  @Min(18)
  private int age;

  // getters and setters
}

What happens if a request sends username=null and age=16 when validated with @Valid?

medium

A. Validation fails for both username and age fields

B. Validation passes because age is int and can't be null

C. Validation fails only for age field

D. Validation passes because @NotNull is ignored on String

Solution

1. Step 1: Check username validation

   @NotNull on username means null value is invalid, so username=null fails validation.

2. Step 2: Check age validation

   @Min(18) means age must be at least 18. Given age=16, this fails validation.

3. Final Answer:

   Validation fails for both username and age fields -> Option A

4. Quick Check:

   @NotNull + @Min(18) fail for null and age 16 [OK]

Hint: Check each annotation rule against input values [OK]

Common Mistakes:

• Assuming int fields can't fail validation
• Ignoring @NotNull effect on String
• Thinking validation passes if one field is valid

4. Identify the error in this controller method for validating a DTO:

@PostMapping("/users")
public ResponseEntity<String> addUser(UserDTO user) {
  // save user
  return ResponseEntity.ok("User added");
}

medium

A. Missing @Validated annotation on controller class

B. Method should return void instead of ResponseEntity

C. Missing @RequestBody annotation on UserDTO parameter

D. No error, code is correct

Solution

1. Step 1: Check parameter annotations

   To validate JSON input as DTO, @RequestBody is needed to bind request body to UserDTO.

2. Step 2: Check validation annotation

   @Valid is also needed to trigger validation, but missing @RequestBody causes binding failure first.

3. Final Answer:

   Missing @RequestBody annotation on UserDTO parameter -> Option C

4. Quick Check:

   @RequestBody needed for JSON binding [OK]

Hint: Use @RequestBody to bind JSON to DTO [OK]

Common Mistakes:

• Forgetting @RequestBody causes no binding
• Thinking @Valid alone binds JSON
• Assuming return type must be void

5. You want to validate a DTO with a nested object, where the nested object also needs validation. Which is the correct way to enable validation on the nested DTO field?

hard

A. Add @Valid annotation on the nested DTO field inside the parent DTO

B. Add @NotNull on the nested DTO field only

C. Add @Valid on the parent DTO class only

D. No annotation needed, nested DTOs are validated automatically

Solution

1. Step 1: Understand nested validation

   Spring Boot requires @Valid on nested DTO fields to trigger validation of inner objects.

2. Step 2: Why @Valid on nested field

   @NotNull only checks presence, but @Valid triggers validation of nested object's fields.

3. Final Answer:

   Add @Valid annotation on the nested DTO field inside the parent DTO -> Option A

4. Quick Check:

   @Valid on nested field triggers inner validation [OK]

Hint: Use @Valid on nested DTO fields for full validation [OK]

Common Mistakes:

• Using only @NotNull on nested DTO
• Assuming parent @Valid covers nested fields
• Skipping @Valid and expecting automatic nested validation