Validation using @Valid.

Hook: Interviewers love this question because @Valid is the gatekeeper that stops bad REST input before it turns into a production bug.

Question: What does validation using @Valid mean in Spring Boot REST APIs?

Answer: @Valid tells Spring to check an incoming object against Bean Validation rules such as @NotBlank, @Email, and @NotNull. If the object breaks those rules, Spring rejects the request with a 400 Bad Request instead of calling your business code. In Spring Boot 3, the annotations come from jakarta.validation, and the usual validation engine is Hibernate Validator.

Interview-Ready Answer: I use @Valid on controller inputs so Spring automatically validates the request DTO before my endpoint logic runs. If a field is missing or wrong, Spring returns a 400 and I can send back clean field errors instead of letting bad data reach the service layer. The important detail is that @Valid is the trigger, while the actual rules live on the DTO using constraints like @NotBlank and @Email.

What @Valid really does

@Valid is a standard Bean Validation annotation. Bean Validation means a set of rules for checking Java objects, usually at the boundary of your app, such as REST requests. Spring Boot wires this into MVC so that when a controller method receives a DTO, Spring can ask the validator to inspect it.

How it works under the hood

1. Spring MVC reads the JSON request body and uses Jackson to convert it into your DTO.
2. When Spring sees @Valid on the parameter, it asks the Bean Validation engine to validate that object.
3. The validator checks every constraint annotation on the DTO, such as @NotBlank or @Email.
4. If a field is itself an object and is marked with @Valid, Spring cascades validation into that nested object too. Cascade means it keeps walking the object graph instead of stopping at the first level.
5. If violations exist, Spring returns a 400 response. For @RequestBody, the usual exception is MethodArgumentNotValidException, which you can convert into a friendly error payload.

When and why to use it

Use @Valid for API input that must be structurally correct before your app can trust it: names, emails, required IDs, nested address objects, and so on. It is ideal for request DTOs because it keeps your controller thin and your service layer free from repetitive null checks. For complex business rules, use custom validators or service checks, because @Valid is best at input shape and basic correctness, not database logic.

@Valid vs @Validated

Simple rule: use @Valid for request bodies, and reach for @Validated when you need method-level checks or validation groups.

Performance and edge cases

Validation cost is roughly O(n) in the number of constrained fields plus nested objects. For a normal REST DTO, the work is tiny, often microseconds to a low millisecond range. The real slowdown comes from custom validators that hit a database or another service.

• Null vs blank: most constraints ignore null unless you add @NotNull. For strings, @NotBlank catches empty or whitespace-only input.
• Nested objects: add @Valid on the nested field, or the inner object will not be checked.
• Partial updates: a PATCH request often needs different rules, so use validation groups or a separate DTO instead of reusing the create DTO.
• Boot versions: Spring Boot 3 uses jakarta.validation; older Boot 2 code often used javax.validation.

Memory hook: think of @Valid as a bouncer at the REST door: it checks the guest list before anyone enters the club.

Real-world story

Imagine a checkout service for an e-commerce app. The frontend sends a customer name, email, shipping address, and phone number. Without @Valid, an empty email or missing address can slip into the service layer and fail later when the app tries to send a receipt or save the order. That turns a simple client mistake into a noisy 500 error.

What goes wrong in production? You start seeing logs like ConstraintViolationException in some places, NullPointerException in others, and customer support reports that checkout sometimes “spins” and then fails. The user impact is painful: orders are not created, payment may already be authorized, and your team has to reconcile broken state. With @Valid, the API returns a clean 400 immediately, the UI can highlight the bad field, and the failure stays cheap and understandable.

Follow-up & Tricky Questions:

• What happens when @Valid fails on @RequestBody? Spring raises MethodArgumentNotValidException and returns 400. In real apps, you usually catch it with @RestControllerAdvice so the client gets readable field errors.
• How do you validate nested objects or lists? Put @Valid on the nested field, and use validation annotations on the nested DTO itself. For collections, validate each element so one bad child item does not slip through.
• When should I use @Validated instead of @Valid? Use @Validated when you need validation groups or method parameter validation such as @PathVariable, @RequestParam, or service methods. @Valid is the standard trigger for object graphs like request DTOs.
• How do you return custom validation messages? Read the field errors from BindingResult or MethodArgumentNotValidException and map them into your own response model. That keeps the API stable and user-friendly.
• Can I make my own rule? Yes. You create a custom constraint annotation plus a validator class for special checks like “email must be unique” or “date must be in the future.”
• Does @Valid validate null by itself? No. Most constraints ignore null; you need @NotNull if the field must be present. This is one of the most common misunderstandings.
• Is @Valid enough for a PATCH endpoint? Often no. PATCH usually means partial data, so a create-style DTO with many required fields will reject legitimate partial updates. Use a dedicated DTO or validation groups.
• Does @Valid automatically check database rules? No. It checks object state, not business truth. If you need to confirm an ID exists or a username is unique, that logic belongs in a custom validator or service.

Common Mistakes:

• Forgetting the validation dependency. Fix: add spring-boot-starter-validation so Spring has a validator on the classpath.
• Using @NotBlank for non-strings or expecting it to catch null everywhere. Fix: choose the right constraint: @NotNull for presence, @NotBlank for text, @Positive for numbers.
• Putting @Valid on the controller but forgetting nested @Valid on child objects. Fix: cascade validation explicitly into nested DTOs.
• Reusing one DTO for create, update, and patch. Fix: use separate DTOs or validation groups so required fields match the operation.

Memory Hook: Think: “Valid before value.” The request must pass the bouncer before your code gives it business meaning.

Cheat Sheet:

• @Valid triggers Bean Validation on a DTO.
• Rules live on fields with annotations like @NotBlank, @Email, and @NotNull.
• Invalid @RequestBody input usually becomes 400 Bad Request.
• Use @Validated for groups and method parameter checks.
• Nested objects need cascading validation with @Valid again.
• Most constraints ignore null unless you add @NotNull.

Practice Tasks:

• Add a List<AddressRequest> field and make sure each item is validated.
• Create a custom annotation like @StrongPassword and reject weak passwords.
• Change the controller to support PATCH with a separate update DTO and test which fields should be optional.