🧠 What REALLY Happens When You Hit a Spring Boot REST API?

💥 Inside the Hidden World of Filters, Interceptors & DispatcherServlet

---

🎬 Intro: “It’s Just a Simple API Call…” — Said Every Developer Before Debugging It

You hit this:

GET http://localhost:8080/api/user/42

🎯 And your controller returns the user info. Done, right?

😏 LOL no.

Welcome to Spring Boot, where your request goes on a rollercoaster ride through filters, interceptors, servlet containers, exception resolvers, and more — before it even thinks about reaching your controller.

Let’s deep-dive into the secret life of a REST API call in Spring Boot — with 🔍 internal mechanics, 😱 common mistakes

---

⚙️ 1. 🚪 The Request Arrives at... The Bouncer (Tomcat)

Spring Boot has an embedded server (usually Tomcat). When your app starts, it's like opening a door at a nightclub. The request knocks. 🕺

Tomcat says:
"Who dis? 🤨"
And then it lets the HTTP request enter.

🧠 Technically: Tomcat parses the socket connection and sends the request into the Servlet layer.

---

🧰 2. 🚓 Filters Step In – “We Check Everyone!”

@Component
public class MyFilter implements Filter {
    public void doFilter(...) {
        // CORS? Auth header? Logging? All here
        chain.doFilter(request, response);
    }
}

🔍 What They Do:

• Logging 🪵
• Header checks 🧾
• CORS setup 🌐
• JWT parsing 🔐

⚠️ Can’t access Spring beans easily (they live in the servlet world 🌍).

Joke:
“Filters are like your mom at the door. If your hair’s messy or token is missing, she won’t let you go to the party.” 😆

---

🧠 3. 🎩 Enter the DispatcherServlet — The Real Boss

Spring's legendary DispatcherServlet is the Front Controller.

It’s the guy in the suit standing behind the scenes, pointing where every request should go.

@Bean
public DispatcherServlet dispatcherServlet() {
    return new DispatcherServlet();
}

🧭 Responsibilities:

• Picks the right controller 🤖
• Handles exceptions 💥
• Sends responses 💌
• Makes sure your REST endpoint actually gets called

---

🚦 4. 🕵️ Interceptors Arrive – “We See What You Do”

Unlike filters, interceptors live in Springland, where you get DI, beans, and control. 😎

@Component
public class MyInterceptor implements HandlerInterceptor {
    public boolean preHandle(...) { }
    public void postHandle(...) { }
    public void afterCompletion(...) { }
}

✅ preHandle() — Before Controller

• Block request? Return false. 🚫
• Start timing? ⏱️
• Check session? 🔑

🔄 postHandle() — After Controller

• Modify ModelAndView 🎭
• Log what controller returned ✅
• Inject extra data before view is rendered 🌈

🚫 You can't modify the JSON response here if it’s a REST controller.

🔚 afterCompletion() — After Response Sent

• Log request duration ⏱️
• Cleanup (ThreadLocal, MDC) 🧹
• Log exceptions 🤕

❌ You cannot modify the response here; it’s already committed!

---

🎯 5. 🎯 Handler Mapping – “Where’s This Request Supposed to Go?”

Spring finds the matching controller based on:

• URL path 🛣️
• HTTP method 🔄
• Annotations like @GetMapping, @PostMapping

@GetMapping("/api/user/{id}")
public User getUser(@PathVariable Long id) {
    return userService.findUser(id);
}

---

🤖 6. Your Controller Finally Runs 🎉

Spring injects everything you love:

• @PathVariable, @RequestParam, @RequestBody
• Autowired beans
• RequestContext, Headers, etc.

---

💣 7. Boom! Exceptions? Enter @ControllerAdvice 💬

@ControllerAdvice
public class MyErrorHandler {
    @ExceptionHandler(UserNotFoundException.class)
    public ResponseEntity<?> handleIt() {
        return ResponseEntity.status(404).body("No user, bro!");
    }
}

✅ Spring checks for matching exception handlers.
❌ If none are found → you get a white-label error page (uglyyyy).

---

📤 8. Response Goes Back (Backwards Flow)

The response now goes through:

1. ResponseBodyAdvice 🛠️
2. Interceptors: postHandle() → afterCompletion() 🔄
3. Servlet Filters (again) 🚦
4. Embedded server (Tomcat) ✉️
5. The client gets the final response 🎉

---

🗺️ The Full Lifecycle Map

Client
 ↓
🌐 Embedded Server (Tomcat)
 ↓
🚓 Filters (Servlet API)
 ↓
🎩 DispatcherServlet
 ↓
🕵️ Interceptor.preHandle()
 ↓
🧭 Handler Mapping
 ↓
🎯 Controller Logic
 ↓
🧹 Interceptor.postHandle()
 ↓
📦 ResponseBodyAdvice
 ↓
🧼 Interceptor.afterCompletion()
 ↓
🛂 Filters (post)
 ↓
✉️ Response to Client

---

🎯 Should I Set Headers in a Filter or an Interceptor? 🤔

Great question! You might be wondering:

“If I can add headers in a filter, why should I ever use an interceptor?” 🤨

🛠️ Short Answer:

✅ Both can add headers.
🚫 But filters don’t know which controller is being called.
💡 Interceptors do, and they have full Spring context.

---

🔬 Case Studies to Compare

1️⃣ Global Headers — Use a Filter ✅

// Filter example
response.setHeader("X-App-Version", "1.0.9");
response.setHeader("X-Frame-Options", "DENY");

Perfect for:

• CORS headers 🌐
• Security headers 🔐
• Trace IDs 🧵

2️⃣ Controller-Specific Headers — Use an Interceptor 💡

// Interceptor example
public void postHandle(...) {
  if (handler instanceof HandlerMethod hm &&
      hm.hasMethodAnnotation(MySpecialHeader.class)) {
      response.setHeader("X-Special", "true");
  }
}

Interceptors know:

• Which controller method is running 🧠
• What annotations are present 🔍
• Can access Spring beans! 🌱

3️⃣ Modify Headers After Controller — Use Interceptor or ResponseBodyAdvice 🔁

If your controller is REST and you need to add headers *after* business logic:

• ✅ Interceptor’s postHandle() (for headers)
• ✅ ResponseBodyAdvice (for body + headers💬 Interviewer May Ask:

“Can you set headers in a filter?” ✅ Yes, but only generic ones.
“Can you modify headers based on the controller?” ❌ Not in filters. ✅ Use interceptors!

🎯 Rule of Thumb:

• Use filters when you need to do something BEFORE Spring kicks in
• Use interceptors when you want access to Spring context, beans, and controller logic

---

🎁 Bonus Tip:

For REST APIs, add metadata headers like:

response.setHeader("X-Request-ID", requestId);
response.setHeader("X-User-ID", userId);

This helps in:

• 🌐 Distributed tracing
• 🔍 Debugging logs across microservices
• 📈 Monitoring APIs under load

---

💬 What About You?

Ever confused filters and interceptors in a live project or interview? 😅 Did someone add response headers in afterCompletion() and wonder why they didn't show up?

Share your war stories in the comments below 👇

🧪 Interview Questions You’ll Crush After Reading This

❓ Question	✅ Answer
Filter vs Interceptor?	Filter = Servlet level Interceptor = Spring MVC level
Can I block request in preHandle()?	Yes, return false to stop the flow
Can I modify response in afterCompletion()?	❌ No. Response already committed
Where to log time taken?	afterCompletion() is ideal ⏱️
Filter throws exception. Who handles it?	Global exception handler won’t catch unless inside Spring context

---

🪄 Wrapping Up: You Just Became a Request Flow Wizard 🧙

Most devs debug controller issues without knowing filters or interceptors even touched the request.
But not you. 💪 You now know exactly who does what, when, and why.

Whether it’s logging, security, tracing, or performance — this internal flow gives you superpowers in both interviews and real projects.

💬 Your Turn:

Ever spent hours debugging a request that mysteriously vanished? Was it a filter, a missing header, or a short-circuiting preHandle()? 😅 Drop your war stories in the comments 👇

---