Introduction

When an IDE says a Spring Boot @RestController is "never used," it usually does not mean the controller is broken. It usually means the IDE is looking for ordinary Java call sites, while Spring discovers and invokes controllers indirectly through component scanning and HTTP request mapping.

Why the Warning Appears

A controller method is not normally called directly by your own code. Spring creates the application context, scans for beans, detects request mappings, and invokes the matching method when an HTTP request arrives.

This controller is perfectly valid even though no Java code calls it explicitly:

1import org.springframework.web.bind.annotation.GetMapping;
2import org.springframework.web.bind.annotation.RestController;
3
4@RestController
5public class HealthController {
6
7    @GetMapping("/health")
8    public String health() {
9        return "ok";
10    }
11}

An IDE inspection can mark the class or method as unused because it is not seeing Spring's runtime wiring.

Make Sure the Controller Is Actually Discoverable

Even though the warning is often harmless, you should still verify that the controller is in a package scanned by Spring Boot.

The usual structure is:

1package com.example.demo;
2
3import org.springframework.boot.SpringApplication;
4import org.springframework.boot.autoconfigure.SpringBootApplication;
5
6@SpringBootApplication
7public class DemoApplication {
8    public static void main(String[] args) {
9        SpringApplication.run(DemoApplication.class, args);
10    }
11}

If DemoApplication is in com.example.demo, Spring Boot scans that package and its subpackages by default. A controller under com.example.demo.api will be found. A controller under some unrelated package may not be.

Verify with a Real Endpoint

The fastest way to prove the controller is actually used is to run the app and call the endpoint.

curl http://localhost:8080/health

If the response comes back, the controller is being discovered and invoked correctly regardless of the IDE warning.

You can also add a simple test:

1import static org.springframework.test.web.servlet.request.MockMvcRequestBuilders.get;
2import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.content;
3import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.status;
4
5import org.junit.jupiter.api.Test;
6import org.springframework.beans.factory.annotation.Autowired;
7import org.springframework.boot.test.autoconfigure.web.servlet.AutoConfigureMockMvc;
8import org.springframework.boot.test.context.SpringBootTest;
9import org.springframework.test.web.servlet.MockMvc;
10
11@SpringBootTest
12@AutoConfigureMockMvc
13class HealthControllerTest {
14
15    @Autowired
16    private MockMvc mockMvc;
17
18    @Test
19    void healthEndpointReturnsOk() throws Exception {
20        mockMvc.perform(get("/health"))
21            .andExpect(status().isOk())
22            .andExpect(content().string("ok"));
23    }
24}

That is a much better signal than an unused-code inspection.

When the Warning Does Point to a Real Problem

Sometimes the controller really is not active. Common causes include:

• The class is outside the component-scan path.
• 'spring-boot-starter-web is missing.'
• The application is using a different web stack than expected.
• The request mapping path is wrong.
• The controller bean is excluded by configuration.

If curl returns 404, the issue is no longer just an IDE message. At that point, inspect package layout, starters, and request mappings.

Common Pitfalls

The most common mistake is deleting or refactoring a working controller just because the IDE says it is unused. Framework-managed entry points often look unused to static inspection tools.

Another issue is assuming the warning is always harmless. It is usually harmless, but you still need to confirm that the application can actually route requests to the controller.

Developers also sometimes place controllers in packages that are siblings of the main application package instead of children. Spring Boot's default scanning is package-based, so structure matters.

Finally, do not rely only on IDE coloring or inspections for framework behavior. Run the application, hit the endpoint, and add tests for critical mappings.

Summary

• '@RestController classes often look unused because Spring invokes them reflectively at runtime.'
• The warning is usually an IDE inspection issue, not a Spring Boot bug.
• Confirm the controller is under the application's component-scan path.
• Test the endpoint with curl or MockMvc instead of trusting the unused warning.
• Treat 404 or missing mappings as real configuration problems, not just IDE noise.