Module 19: Advanced Capstone Portfolio
Capstone 4: REST API with Persistence
Build a REST API with persistence that feels coherent from HTTP boundary to database write. This capstone is a portfolio-ready backend project when it shows layering, validation, transaction boundaries, and a clean data model rather than a random pile of endpoints.
Author
Java Learner Editorial Team
Reviewer
Technical review by Java Learner
Last reviewed
2026-04-17
Java version
Java 25 LTS
Learning goals
- Design an end-to-end API with controllers, services, repositories, and persistence
- Apply validation, mapping, and error handling consistently across endpoints
- Produce a backend project that another developer could run and understand quickly
Before you start
- You completed the earlier advanced modules or can already build small Java applications independently
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.
Project goal: Build a REST API for tasks, books, inventory, or another domain with full CRUD and clean architecture.
What to practice: Controllers, services, repositories, DTOs, validation, transactions, and tests.
Stretch ideas: Add authentication, pagination, filtering, or background jobs.
Success check: The API should feel like something another developer could extend without rewriting the whole project.
Project goal: Choose one domain such as tasks, books, tickets, or notes, then implement a focused set of endpoints for create, read, update, and one domain-specific action.
Suggested architecture: DTOs at the HTTP boundary, service methods for business rules, repositories for persistence, and one exception strategy that maps failures to clean API responses.
Milestone plan: Start with one GET and one POST endpoint, add persistence, add update behavior, add validation and not-found handling, then add pagination or filtering.
Stretch ideas: Add search, pagination, audit fields, or authentication later. A small but clean API is a stronger portfolio piece than a wide but inconsistent one.
How to use the capstones: Build them like portfolio pieces, not toy exercises. Write down the scope first, finish a thin vertical slice, and only then add polish, tests, extra features, or deployment steps.
Project review mindset: A strong capstone shows design choices, not just code volume. Clear boundaries, naming, validation, error handling, and a short README often matter more than adding ten extra features.
Delivery habit: Each finished project should include a problem statement, setup instructions, example input and output, and at least one obvious next improvement for future iteration.
Runnable examples
A layered API starts with clear boundaries
controller -> service -> repositoryExpected output
Each layer owns one responsibility instead of mixing HTTP, business rules, and persistence together.
A layered API begins with a clear service contract
interface TaskService {
TaskDto create(CreateTaskRequest request);
List<TaskDto> list();
}Expected output
The controller can stay thin because the service contract defines the application behavior clearly.
Common mistakes
Using entities as request and response bodies because it is faster at the start
Use DTOs from the beginning so the API contract stays clean as persistence evolves.
Adding many endpoints before basic error handling and validation are stable
Complete a small reliable API surface first, then widen the surface area.
Mini exercise
Write the first three endpoints for your API, the DTOs they use, the status codes they return, and one error case for each.
Summary
- This capstone pulls together the full backend path.
- Layer boundaries matter as much as endpoint count.
- Testing and validation are part of the core design, not add-ons.
- A strong REST capstone proves consistent boundaries more than it proves framework familiarity.
- Build outward from one clean slice instead of inward from many half-defined endpoints.
Next step
The final capstone combines several advanced areas into one more production-minded application.
Sources used