Module 17: Spring Boot Service Development
REST Controllers, DTOs, and Validation
Design clear REST endpoints with validation and DTO boundaries so your HTTP layer stays predictable as the application grows. This lesson focuses on request and response shapes, status codes, validation flow, and where controller responsibilities should stop.
Author
Java Learner Editorial Team
Reviewer
Technical review by Java Learner
Last reviewed
2026-04-17
Java version
Java 25 LTS
Learning goals
- Separate HTTP contract models from persistence or domain internals
- Apply validation close to the API boundary and return helpful failures
- Keep controllers thin by moving rules and orchestration into services
Before you start
- You understand classes, objects, exceptions, collections, and basic persistence concepts
Lesson roadmap: Start with the mental model, then follow the design choices, common pitfalls, and the practical workflow you should apply in a real project.
A REST controller turns HTTP requests into Java method calls: It handles request mapping, input binding, and response shaping.
DTOs are important boundaries: They keep the HTTP contract separate from internal persistence objects and domain details.
Validation belongs at the edge: Invalid input should be rejected as early as possible instead of leaking into the service layer.
Advanced habit: Keep controllers thin. Their job is translation and validation, not core business logic.
Controller responsibility: A controller should translate HTTP into application calls and translate results or failures back into HTTP responses. It should not become the place where business rules, mapping, and persistence all mix together.
DTOs protect the boundary: Request DTOs describe what clients may send, response DTOs describe what clients may see, and entities stay internal unless you have a very strong reason to expose them directly.
Validation flow: Validate basic structure and field rules at the boundary, then apply business validation in the service layer. This split keeps the API clear without pretending every rule is just a bean-validation annotation.
HTTP design checklist: Choose consistent paths, verbs, response codes, and error shapes. Clients trust an API more when failures are as predictable as successes.
How to study this module: Keep one small service running while you learn. Seeing one controller call one service and one repository is much easier than reading isolated annotations with no end-to-end flow.
Code review mindset: Spring code stays healthy when each layer has one job. Controllers translate HTTP, services coordinate rules, repositories load and save data, and configuration wires the environment together.
Production habit: Favor explicit boundaries over framework magic. Auto-configuration is helpful, but teams still need to know where behavior comes from and how to override it safely.
Runnable examples
A small REST endpoint
@RestController
@RequestMapping("/tasks")
class TaskController {
@GetMapping("/{id}")
public TaskDto getTask(@PathVariable long id) {
return new TaskDto(id, "Learn Spring");
}
}Expected output
A GET request to `/tasks/1` can return a DTO response.
Validation belongs on the request model, not on random controller locals
record CreateTaskRequest(@jakarta.validation.constraints.NotBlank String title) {}
@PostMapping
TaskDto create(@Valid @RequestBody CreateTaskRequest request) {
return service.create(request);
}Expected output
The request is validated at the boundary before the service continues the workflow.
Common mistakes
Returning JPA entities directly from the controller
Use DTOs so the HTTP contract stays stable and does not accidentally expose lazy relationships or internal fields.
Putting business rules directly in controller methods because the endpoint is small “for now”
Even small APIs age better when controllers stay thin and services own business decisions.
Mini exercise
Design one POST endpoint for creating tasks and one GET endpoint for listing them. Write the request DTO, response DTO, expected status codes, and one validation error example.
Summary
- Controllers translate HTTP into application calls.
- DTOs protect the boundary between the API and the domain model.
- Validation should happen at the request edge.
- REST quality depends on boundary discipline as much as on annotation knowledge.
- DTOs and validation keep the API predictable while services keep business rules centralized.
Next step
Next, connect controllers to data access more cleanly with Spring Data JPA.
Sources used