基于@Controller+@ResponseBody的旧版Spring Boot REST API解析

先看项目里的这段旧版API代码：

@ResponseBody
@RequestMapping(value = "/save", method = RequestMethod.POST, produces = "application/json")
public ResponseEntity<String> save(@RequestBody String input) {

    JSONObject response = new JSONObject();

    try {

        JSONObject request = new JSONObject(input);

        if (request.isNull("name")) {
            return new ResponseEntity<>("Invalid input", HttpStatus.BAD_REQUEST);
        }

        JSONObject result = service.save(request);

        return new ResponseEntity<>(result.toString(), HttpStatus.OK);

    } catch (Exception e) {

        response.put("message", e.getMessage());

        return new ResponseEntity<>(response.toString(), HttpStatus.UNAUTHORIZED);
    }
}

针对你提出的疑问，逐一解答：

1. 该写法仍属于REST API架构范畴吗？ #

属于。它符合REST的核心特征：基于HTTP协议、用POST方法处理资源保存请求、返回标准HTTP状态码、输出JSON格式响应。只是没有用Spring提供的简化注解，本质还是REST API。

2. 此代码风格是否基于早期Spring MVC模式？ #

是的。@ResponseBody+@RequestMapping的组合是Spring MVC早期构建REST接口的标准写法，后来Spring 4.0推出@RestController（相当于@Controller+@ResponseBody的组合注解），同时@PostMapping等方法级注解也是对@RequestMapping(method=RequestMethod.POST)的简化，这段代码完全是早期Spring MVC的风格。

3. 为何部分企业项目仍沿用这类旧版风格？ #

• 历史遗留：项目从早期Spring版本迭代过来，团队一直沿用原有写法，没有动力重构；
• 团队习惯：老开发人员熟悉这套写法，不想学习新注解，或者担心重构引入风险；
• 兼容性考虑：部分老旧依赖或自定义组件和新注解存在兼容问题，不敢轻易替换；
• 保守决策：企业项目注重稳定性，除非有明确性能或维护性收益，不会随意改动现有成熟代码。

4. 旧项目中手动解析JSONObject是否属于常见操作？ #

非常常见。在Spring还没有完善的DTO自动序列化/反序列化机制之前，很多项目会用JSONObject（比如org.json、FastJSON这类库）手动处理JSON字符串，这种方式灵活但繁琐，后来Spring默认集成Jackson后，才普遍用DTO配合@RequestBody/@ResponseBody自动完成序列化。

5. 我需要学习哪些内容才能高效理解并维护这类代码库？ #

• 早期Spring MVC核心API：重点掌握@RequestMapping的参数配置、@ResponseBody的作用、ResponseEntity的用法；
• JSON手动处理库：了解项目用的是org.json、FastJSON还是其他JSON工具类的API，熟悉它们的解析、生成方法；
• HTTP状态码的项目约定：这类项目对状态码的使用可能和现代写法有差异，比如示例里把所有异常都返回401，需要熟悉项目内部的状态码规则；
• 项目的异常处理逻辑：这类项目通常没有统一异常处理器，多是手动捕获异常并构造响应，要理清各个接口的异常处理规则；
• 历史代码的设计思路：了解项目当初选择这种写法的原因，比如是否有特定的业务需求或技术限制，能帮你更快上手维护。

内容的提问来源于stack exchange，提问作者BHARATH VAMSI MANIKANTA REDDY