Spring是否有捕获HTTP请求方法的注解？遗留控制器场景

嗨，这个场景我太熟了！完全不用手动调用HttpServletRequest.getMethod()，用Spring自带的注解和特性就能完美解决，还能保持你的代码风格统一。下面给你两种实用方案，按需选择：

方案一：拆分请求方法（推荐，符合单一职责） #

这是最规范的做法，把原来的通用方法拆分成专门处理POST的方法，以及处理PUT/PATCH并抛出错误的方法，逻辑清晰，后续维护也方便：

代码示例 #

// 专门处理POST请求，加入新增的仅POST功能
@PostMapping("/api/your-resource")
public ResponseEntity<?> handlePostRequest(@RequestBody YourResourceDto dto) {
    // 原有通用业务逻辑
    processCommonLogic(dto);
    // 新增的仅POST专属功能
    executePostOnlyFeature(dto);
    return ResponseEntity.ok(dto);
}

// 处理PUT请求，直接抛出错误
@PutMapping("/api/your-resource")
public ResponseEntity<?> handlePutRequest() {
    throw new CustomMethodNotAllowedException("仅支持POST请求，PUT请求已被禁用");
}

// 处理PATCH请求，直接抛出错误
@PatchMapping("/api/your-resource")
public ResponseEntity<?> handlePatchRequest() {
    throw new CustomMethodNotAllowedException("仅支持POST请求，PATCH请求已被禁用");
}

说明 #

• @PostMapping、@PutMapping、@PatchMapping都是Spring提供的注解缩写，本质是@RequestMapping(method = RequestMethod.XXX)，代码更简洁。
• 你可以自定义CustomMethodNotAllowedException异常，配合全局异常处理器返回友好的错误响应；如果只想返回标准的405状态码，甚至可以不用写PUT/PATCH的方法，Spring会自动返回405，但自定义异常能提供更明确的业务提示。

方案二：不拆分原有方法，注入HttpMethod判断 #

如果原有方法的逻辑特别复杂，拆分成本高，可以直接在方法参数里注入Spring的HttpMethod对象，做判断后抛错，比直接用HttpServletRequest更贴合Spring风格：

代码示例 #

@RequestMapping(value = "/api/your-resource", method = {RequestMethod.POST, RequestMethod.PUT, RequestMethod.PATCH})
public ResponseEntity<?> handleRequest(@RequestBody YourResourceDto dto, HttpMethod requestMethod) {
    // 非POST请求直接抛错
    if (!HttpMethod.POST.equals(requestMethod)) {
        throw new HttpRequestMethodNotSupportedException(requestMethod.name());
    }
    
    // 原有通用业务逻辑
    processCommonLogic(dto);
    // 新增的仅POST专属功能
    executePostOnlyFeature(dto);
    return ResponseEntity.ok(dto);
}

说明 #

• HttpMethod是Spring封装的请求方法枚举，比原生的HttpServletRequest更优雅，不用手动解析字符串。
• HttpRequestMethodNotSupportedException是Spring自带的异常，抛出后Spring会自动返回405状态码，也可以替换成你自定义的异常。

两种方案都完全符合你的需求，不用依赖原生请求对象，保持Spring注解的代码风格。个人更推荐方案一，代码结构更清晰，符合Spring的最佳实践～

内容的提问来源于stack exchange，提问作者satishkk