Fix Spring Boot Request Method Not Supported Error (2026)

The 5xx error you’re seeing, "Request method 'GET' not supported," means your Spring Boot application received an HTTP GET request but the controller handling that specific URL path doesn’t have a method configured to accept GET requests. It’s a mismatch between what the client asked for and what the server is prepared to do at that endpoint.

Here are the most common reasons this happens and how to fix them:

1. Incorrect HTTP Method Annotation

Diagnosis: Look at your controller class (@RestController or @Controller) and the specific method that’s supposed to handle the request. The @RequestMapping annotation (or its shorthand like @GetMapping, @PostMapping, etc.) on the method needs to match the HTTP method the client is sending.

Cause: You’ve likely annotated the method with the wrong HTTP verb. For instance, you might have a @PostMapping on a method that’s meant to be called with a GET.

Fix: Change the annotation to the correct HTTP method.

If you meant to use GET:
```
@GetMapping("/your/url")
public ResponseEntity<String> handleGetRequest() {
    // ...
}
```
Why it works: @GetMapping is a shorthand for @RequestMapping(method = RequestMethod.GET). This tells Spring to map incoming GET requests to this method.
If you meant to use POST:
```
@PostMapping("/your/url")
public ResponseEntity<String> handlePostRequest() {
    // ...
}
```
Why it works: @PostMapping is a shorthand for @RequestMapping(method = RequestMethod.POST). This tells Spring to map incoming POST requests to this method.

If you need to support multiple methods:

@RequestMapping(value = "/your/url", method = {RequestMethod.GET, RequestMethod.POST})
public ResponseEntity<String> handleMultipleMethods() {
    // ...
}

Why it works: @RequestMapping with an explicit method attribute allows you to specify an array of allowed HTTP methods.

2. Missing `@RequestMapping` or Shorthand Annotation on the Method

Diagnosis: Even if your class has a @RequestMapping annotation, if the specific method isn’t annotated or the class-level mapping doesn’t cover the full path, you’ll get this error.

Cause: The method intended to handle the request is not properly mapped.

Fix: Ensure the method has an appropriate annotation.

If the class has a base path and the method needs its own:

@RestController
@RequestMapping("/api/v1")
public class MyController {

    @GetMapping("/items") // This maps to /api/v1/items
    public ResponseEntity<String> getAllItems() {
        // ...
    }

    // This method is not mapped and will cause issues if called directly
    // public String anotherMethod() { ... }
}

Why it works: Each public method intended to handle web requests must be explicitly mapped using @GetMapping, @PostMapping, @PutMapping, @DeleteMapping, @PatchMapping, or a general @RequestMapping with a method specified.

3. Incorrect Path Mapping

Diagnosis: Double-check the URL path in the client’s request against the path specified in the @RequestMapping or shorthand annotation on your controller method.

Cause: A typo or a mismatch in the URL path between the client and the server. For example, the client requests /users but your controller is mapped to /api/users.

Fix: Align the paths.

Update the controller mapping:
```
@GetMapping("/users") // Ensure this matches the client's request
public ResponseEntity<String> getUsers() {
    // ...
}
```
Why it works: The path attribute in the annotation must precisely match the requested URI path.
Update the client request: If the controller is correctly mapped to /api/users, ensure your client sends requests to that exact path.

4. Spring MVC Configuration Issues (Less Common in Standard Spring Boot)

Diagnosis: If you’ve heavily customized your Spring MVC configuration (e.g., in a @Configuration class), there might be an issue with how request mappings are being processed or registered.

Cause: Custom RequestMappingHandlerMapping or DispatcherServlet configurations might interfere with standard annotation processing.

Fix: Review your custom MVC configuration.

Ensure default configurations are not overridden incorrectly: In a class annotated with @Configuration and @EnableWebMvc (or @Configuration with WebMvcConfigurer implemented):

@Configuration
public class WebConfig implements WebMvcConfigurer {

    @Override
    public void addViewControllers(ViewControllerRegistry registry) {
        // If you're adding view controllers, ensure they don't conflict
        // with your annotated controllers.
    }

    // Examine any custom RequestMappingHandlerMapping beans you might have defined.
    // If you've defined one, ensure it's not disabling annotation processing
    // or overriding default behavior in a way that skips your controllers.
}

Why it works: Spring Boot auto-configures most of this. If you’re manually configuring, you might accidentally disable the components responsible for discovering and registering annotated controller methods.

5. Filter or Interceptor Interfering

Diagnosis: A Filter or HandlerInterceptor in your application might be intercepting the request before it reaches the DispatcherServlet’s mapping logic and returning a response or modifying the request in a way that breaks the mapping.

Cause: A custom filter or interceptor might be prematurely terminating the request chain or altering the request’s properties (like the HTTP method or URI) in an unexpected way.

Fix: Temporarily disable or bypass the suspect filter/interceptor for testing.

Check Filter implementations: If you have custom Filter beans, log their doFilter method to see if they’re processing the request and potentially ending the chain (chain.doFilter(request, response) is not called, or response.isCommitted() becomes true).

// Example of a problematic filter
@Component
public class MyProblematicFilter implements Filter {
    @Override
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
        HttpServletRequest httpRequest = (HttpServletRequest) request;
        // If this condition is met, the request might not reach the controller
        if ("GET".equals(httpRequest.getMethod()) && httpRequest.getRequestURI().startsWith("/api/old/")) {
            response.getWriter().write("Legacy API endpoint handled here.");
            // chain.doFilter is NOT called, terminating the request.
            return;
        }
        chain.doFilter(request, response); // Crucial for continuing the request
    }
}

Why it works: Filters and interceptors execute in a specific order. If one of them decides to handle the request itself without passing it down the chain (chain.doFilter), subsequent handlers (including your controllers) will never see it.

Check HandlerInterceptor implementations: Similar to filters, interceptors can return false from preHandle to stop the request from reaching the controller.

// Example of a problematic interceptor
public class MyProblematicInterceptor implements HandlerInterceptor {
    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        if ("/api/protected".equals(request.getRequestURI())) {
            // If authentication fails, you might want to send an error.
            // But if not done correctly, it could prevent mapping.
            if (!isAuthenticated(request)) {
                response.sendError(HttpServletResponse.SC_UNAUTHORIZED, "Unauthorized");
                return false; // Stops the request from reaching the controller
            }
        }
        return true; // Allows the request to proceed
    }
}

Why it works: The preHandle method of HandlerInterceptor acts as a gatekeeper. Returning false stops the request from being processed by the controller.

6. Conflicting Mappings

Diagnosis: If you have multiple controller methods or even multiple controllers with overlapping URL paths and HTTP methods, Spring might not know which one to pick. This can manifest as a "method not supported" error if the preferred mapping it tries to use doesn’t match the request method, even if another mapping would match.

Cause: Ambiguous endpoint definitions.

Fix: Make your mappings more specific or unique.

Differentiate paths:

// Controller 1
@RestController
@RequestMapping("/api/products")
public class ProductController {
    @GetMapping
    public String getAllProducts() { return "All products"; }
}

// Controller 2 (if this also used @GetMapping and /api/products)
// This would cause ambiguity if not differentiated.
// @RestController
// @RequestMapping("/api/products")
// public class AnotherController { ... }

Why it works: Each endpoint should have a unique combination of path and HTTP method. If there’s ambiguity, Spring might default to a less specific mapping or fail to resolve it, leading to errors.

Differentiate by parameters (less common for method not supported, but possible): While not directly fixing "method not supported" for GET/POST, if you have multiple @GetMapping methods with the same path but different query parameters expected, Spring’s type conversion might fail before the method is chosen, indirectly leading to issues.

The next error you’ll likely encounter, if you’ve fixed the method annotation but the path is still wrong, is a 404 Not Found.