Validation Groups in Spring

Introduction

In the world of REST APIs, data validation is a common challenge. This becomes particularly complex when the same Data Transfer Object (DTO) needs to be validated differently based on the HTTP method used - POST, PATCH, etc. This article aims to explore this problem and present a solution using validation groups in Spring.

The Problem

Consider a scenario where we have a UserDTO that is used in both POST (create user) and PATCH (update user) requests. In a POST request, all fields might be required, but in a PATCH request, only the fields to be updated are provided. How can we apply different validation rules for the same DTO based on the context?

Alternative Approach

One could create separate DTOs for each operation (UserPostDTO, UserPatchDTO). However, this leads to a lot of code duplication and can quickly become unmanageable with many operations.

Validation Groups Approach

Validation groups in Spring provide a clean and efficient solution to this problem. With validation groups, we can define different sets of constraints for the same DTO and choose which set to apply based on the context.

Here’s an example of how to define and use validation groups:

public class UserDTO {

    @Null(groups = OnCreate.class)
    @NotNull(groups = OnUpdate.class)
    private Long id;

    @NotBlank(groups = {OnCreate.class, OnUpdate.class})
    private String name;

    // getters and setters
}

public interface OnCreate {}

public interface OnUpdate {}        

In the above code, OnCreate and OnUpdate are validation groups. When creating a user (POST request), the id field should be null and the name field should not be blank. When updating a user (PATCH request), the id field should not be null.

To validate the DTO, we can use the @Validated annotation in our controller methods:

@PostMapping("/users")
public ResponseEntity<?> createUser(@Validated(OnCreate.class) @RequestBody UserDTO userDTO) {
    // ...
}

@PatchMapping("/users/{id}")
public ResponseEntity<?> updateUser(@PathVariable Long id, @Validated(OnUpdate.class) @RequestBody UserDTO userDTO) {
    // ...
}
        

Default Jakarta Bean Validation Group

By default, unless a list of groups is explicitly defined, constraints belong to the Default group and validation applies to the Default group. Most structural constraints should belong to the default group. This is an important aspect to consider when working with validation groups.

Conclusion

Validation groups in Spring offer a powerful and flexible way to handle complex validation scenarios. They help keep our code clean and maintainable, making them an excellent choice for many applications. However, depending on your application's specific requirements and constraints, other approaches like separate DTOs might be more appropriate. It’s important to choose the approach that best fits your needs. Remember, by default, unless explicitly defined, constraints belong to the Default group and validation applies to the Default group.