When I started building REST APIs with Spring Boot, everything seemed simple.
I wrote a controller.
Mapped a few endpoints.
Returned JSON.
It worked.
But as the project grew, something felt wrong.
My controllers were getting bigger.
Business logic started leaking in.
Request handling became confusing.
That’s when I finally understood the importance of the Presentation Layer.
🧠What is the Presentation Layer (in simple terms)?
The Presentation Layer is the entry point of your Spring Boot application.
It is responsible for:
- Receiving HTTP requests from the client
- Mapping requests to the correct endpoints
- Accepting and converting input data
- Returning responses in JSON/XML
It should not contain business logic.
It should not talk directly to the database.
Its job is simple:
Handle requests → delegate work → return responses
🏗️ The Big Picture: Spring Boot Project Structure
A clean Spring Boot web application usually looks like this:
client
controller
service
dto
repository
entity
database
Here’s the key rule I learned the hard way:
👉 Controllers talk to Services, not to Databases.
Once I followed this, my code became cleaner overnight.
🎮 Controllers: The Heart of the Presentation Layer
Spring MVC gives us an annotation-based programming model to build controllers.
Two important annotations:
@Controller
Used in traditional MVC applications that return views.@RestController
A shortcut for @Controller + @ResponseBody
This means:
Every method inside a @RestController directly returns JSON/XML to the client.
For REST APIs, @RestController is the default choice.
đź”— Request Mapping: How Requests Find Your Code
Spring needs to know which URL maps to which method.
That’s where request mappings come in.
@RequestMapping
A generic mapping that supports:
- URL paths
- HTTP methods
- Headers
- Media types
But in real projects, we mostly use its cleaner alternatives.
🚦 HTTP Method-Specific Mappings (Use These)
Spring provides shortcut annotations that make APIs readable:
- @GetMapping → Fetch data
- @PostMapping → Create data
- @PutMapping → Update data
- @DeleteMapping → Delete data
- @PatchMapping → Partial update
When I started using these properly, my APIs became self-explanatory.
🌍 Dynamic URLs: @PathVariable vs @RequestParam
This confused me a lot initially.
🔹 @PathVariable
Example:
/employees/123
Use this when:
- The value is mandatory
- It uniquely identifies a resource
🔹 @RequestParam
Example:
/employees?id=123
Use this when:
- The parameter is optional
- Used for filtering, sorting, pagination
Once I understood this difference, my API design improved instantly.
📦 Handling Input Data with @RequestBody
When a client sends data (JSON/XML), Spring needs to convert it into a Java object.
That’s where @RequestBody comes in.
It is commonly used in:
- POST
- PUT
- PATCH
Spring uses message converters like Jackson to transform JSON into Java objects automatically.
This is one of those features that feels magical — until you understand it.
⚠️ The Mistake I Was Making
I used to:
- Put logic inside controllers
- Validate data manually
- Call repositories directly
That’s when things broke.
The Presentation Layer is not for business logic.
Once I respected this boundary, my APIs became:
- Cleaner
- Easier to test
- Easier to maintain
🚀 Final Thoughts
The Presentation Layer may look simple, but it decides how clean your backend becomes.
If controllers are clean:
- Services shine
- Bugs reduce
- Scaling becomes easier
Understanding this layer was a turning point in my Spring Boot journey.
This post is part of my learning-in-public journey while exploring Spring Boot and backend development.
Top comments (0)