RESTful API：@RequestParam与@PathVariable实战对比

@RequestParam vs @PathVariable 在删除和查找操作中的使用差异

在项目实战中，选择使用 @RequestParam 还是 @PathVariable 来接收ID参数，通常基于以下几个考虑因素：

1. RESTful API 设计原则

查找操作使用 @PathVariable

@GetMapping("/depts/{id}")
public Result findDept(@PathVariable Integer id) {// 根据ID查找部门
}

• 符合RESTful原则：GET请求用于获取资源，URL格式应为 /资源名/{资源ID}
• 语义清晰：/depts/123 明确表示"获取ID为123的部门"
• 缓存友好：URL路径作为完整资源标识符，更适合浏览器和CDN缓存

删除操作使用 @RequestParam

@DeleteMapping("/depts")
public Result deleteDept(@RequestParam Integer id) {// 根据ID删除部门
}

• 历史惯例：早期REST实践有时对删除操作使用查询参数
• 批量操作考虑：使用查询参数更易于扩展为批量删除（如/depts?id=1,2,3）
• 安全考虑：某些框架对DELETE请求的URL长度限制较严格，查询参数更灵活

2. 实际项目中的常见考量

安全性

• 删除操作更敏感：使用@RequestParam可以将ID放在请求体中而不是URL中，避免被浏览器历史记录、日志等轻易记录
• CSRF防护：某些安全框架对不同类型的参数提取有不同处理方式

前端调用便利性

• 查找操作：前端通常直接拼接URL，@PathVariable方式更直观
• 删除操作：前端可能使用HTTP库发送请求，@RequestParam方式在代码中更明确

API一致性

很多项目会保持一致性，全部使用@PathVariable：

// 一致性更好的做法
@GetMapping("/depts/{id}")
public Result findDept(@PathVariable Integer id) { /* ... */ }@DeleteMapping("/depts/{id}")
public Result deleteDept(@PathVariable Integer id) { /* ... */ }

3. 现代最佳实践

目前更普遍接受的做法是统一使用@PathVariable，因为：

1. 更符合RESTful设计原则
2. URL结构更清晰易读
3. 与HTTP方法语义更匹配（DELETE /resource/{id}）
4. 被大多数API设计指南推荐

4. 示例对比

使用 @PathVariable (推荐)

@RestController
@RequestMapping("/depts")
public class DeptController {@GetMapping("/{id}")public Result findDept(@PathVariable Integer id) {// 查找部门}@DeleteMapping("/{id}")public Result deleteDept(@PathVariable Integer id) {// 删除部门}
}

请求示例：

• 查找：GET /depts/123
• 删除：DELETE /depts/123

使用 @RequestParam (较少见)

@RestController
@RequestMapping("/depts")
public class DeptController {@GetMappingpublic Result findDept(@RequestParam Integer id) {// 查找部门}@DeleteMappingpublic Result deleteDept(@RequestParam Integer id) {// 删除部门}
}

请求示例：

• 查找：GET /depts?id=123
• 删除：DELETE /depts?id=123

5. 结论

在项目实战中，根据ID删除部门使用@RequestParam而查找使用@PathVariable的情况，可能是由于：

1. 历史遗留设计：项目初期设计选择，后续未统一
2. 特定框架限制：某些旧框架对DELETE方法的支持限制
3. 团队约定：特定团队的开发规范
4. 安全考虑：避免敏感操作ID出现在URL中

然而，现代API设计更推荐统一使用@PathVariable，因为它更符合RESTful原则，提供更清晰、一致的API接口。如果项目中存在这种不一致，建议逐步重构为统一风格。