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.