@RequestMapping注解的各个属性作用

1.default-consumes-media-type: multipart/form-data和default-produces-media-type: application/jsondefault-consumes-media-type: multipart/form-data和default-produces-media-type: application/json常见于 API 规范如 OpenAPI或某些框架如 Spring、JAX-RS、Micronaut的配置上下文用于定义接口默认的请求内容类型和默认的响应内容类型。含义解释default-consumes-media-type: multipart/form-data表示接口默认接收的请求数据格式为multipart/form-data。该格式常用于文件上传或混合表单数据文本字段文件。请求体被划分为多个部分parts每个部分可携带不同的数据类型和编码。示例用户头像上传、带附件的表单提交。default-produces-media-type: application/json表示接口默认返回的数据格式为application/json。响应体是标准的 JSON 结构化数据。当前大多数 REST API 使用此格式进行数据交换易于解析和调试。典型使用场景你正在编写一个文件上传 返回 JSON 消息的 API例如客户端通过multipart/form-data上传图片服务端处理后返回{status: success, url: ...}。在OpenAPI (Swagger)或Spring MVC中可以在全局/类级别设定默认的consumes和produces避免每个接口重复声明。例如Spring Boot 示例javaRequestMapping( consumes MediaType.MULTIPART_FORM_DATA_VALUE, produces MediaType.APPLICATION_JSON_VALUE ) public class FileController { ... }OpenAPI 3 全局配置YAML 片段yamlopenapi: 3.0.0 # 某些工具允许设置默认 consumes/produces但标准写法是在路径或操作层指定注意事项这些是默认值你仍然可以为某个具体操作覆盖它们例如某个接口只接收 JSON或返回纯文本。如果你的接口不是全局统一使用multipart/form-data请求建议谨慎设置默认值避免错误地要求所有请求都必须使用该格式。multipart/form-data的请求在 OpenAPI 3 中需要搭配requestBody.content.multipart/form-data.schema描述各 part 的结构。2.RequestMapping及派生注解RequestMapping源码是 Spring Web 中所有请求映射的根本注解。下面我会逐属性解释并说明它与PostMapping、GetMapping等派生注解的关系。一、RequestMapping各属性含义与作用属性类型默认值作用说明nameString为映射指定一个逻辑名称用于辅助工具如 Swagger生成文档或在日志中识别不参与实际匹配。value/pathString[]{}两者互为别名用于指定请求的URI 路径模式。支持通配符、路径变量。例如/users、/users/{id}。methodRequestMethod[]{}限制 HTTP 请求方法GET, POST, PUT, DELETE…。若不指定则匹配所有 HTTP 方法。paramsString[]{}限制请求参数条件。要求请求必须包含/不包含某些参数或参数值等于/不等于某个值。例如version2、!draft。headersString[]{}限制 HTTP 请求头条件。语法与params类似例如X-Requested-WithXMLHttpRequest。consumesString[]{}限制请求的媒体类型即Content-Type头。仅当客户端发送的Content-Type匹配时才会匹配否则返回 415。例如application/json。producesString[]{}限制响应的媒体类型通过Accept头协商。若客户端Accept不匹配则返回 406同时会设置响应Content-Type。例如application/json。注value与path通过AliasFor互称为别名因此两者等价若都不指定则默认映射到类或方法所在路径的相对路径例如类上RequestMapping(/api)方法上无路径则方法映射到/api。二、PostMapping、GetMapping等是如何派生出来的Spring 提供了多个组合注解Composed Annotation每个都固定了method属性并继承了RequestMapping的所有其他能力。例如javaRequestMapping(method RequestMethod.GET) public interface GetMapping { // 通过 AliasFor 将属性桥接到 RequestMapping }注解固定 method等价写法GetMappingRequestMethod.GETRequestMapping(method GET)PostMappingRequestMethod.POSTRequestMapping(method POST)PutMappingRequestMethod.PUTRequestMapping(method PUT)DeleteMappingRequestMethod.DELETERequestMapping(method DELETE)PatchMappingRequestMethod.PATCHRequestMapping(method PATCH)以你给出的PostMapping源码为例javaRequestMapping(method {RequestMethod.POST}) // 元标注固定为 POST public interface PostMapping { AliasFor(annotation RequestMapping.class) String name() default ; AliasFor(annotation RequestMapping.class) String[] value() default {}; AliasFor(annotation RequestMapping.class) String[] path() default {}; // ... 其他属性同样通过 AliasFor 桥接到 RequestMapping }开发者使用PostMapping时无需再写method POST。所有AliasFor声明的属性最终会“传值”给元注解RequestMapping的同名属性。因此PostMapping(/user)等价于RequestMapping(value /user, method POST)。为什么需要这些派生注解简化减少重复编写method …。语义清晰注解名称直接表达了 HTTP 方法。便于静态检查IDE 或代码扫描工具可以更准确地识别 HTTP 操作。三、实际使用对照示例使用RequestMapping完整写法javaRestController public class UserController { RequestMapping(value /users, method RequestMethod.POST, consumes application/json) public User create(RequestBody User user) { ... } }等价的PostMapping写法javaPostMapping(value /users, consumes application/json) public User create(RequestBody User user) { ... }同时使用类级别 方法级别javaRequestMapping(/api/v1) // 类前缀 RestController public class UserController { PostMapping(/users) // 实际路径 /api/v1/users public User create(...) { ... } }四、总结表RequestMappingvs 派生注解注解是否固定method主要用途RequestMapping否默认匹配所有通用映射或需要动态方法如自定义条件GetMapping是GET查询、获取资源PostMapping是POST创建资源PutMapping是PUT整体更新资源DeleteMapping是DELETE删除资源PatchMapping是PATCH部分更新资源记住所有派生注解本质上都是RequestMapping的“特化版本”它们共享相同的路径匹配、参数、头、媒体类型等约束能力但强制了一类 HTTP 方法。在日常开发中为了代码简洁和语义清晰推荐优先使用GetMapping、PostMapping等具体注解仅在需要非常规方法如OPTIONS、TRACE或动态方法时再直接使用RequestMapping。