映射请求
本节讨论注解控制器的请求映射。
@RequestMapping
@RequestMapping 注解用于将请求映射到控制器方法。它具有通过 URL、HTTP 方法、请求参数、请求头和媒体类型进行匹配的各种属性。您可以在类级别使用它来表达共享映射,或者在方法级别使用它来缩小到特定端点映射。
还有 @RequestMapping 的 HTTP 方法特定快捷方式变体:
-
@GetMapping -
@PostMapping -
@PutMapping -
@DeleteMapping -
@PatchMapping
前面的注解是自定义注解,它们之所以提供,是因为可以说大多数控制器方法应该映射到特定的 HTTP 方法,而不是使用 @RequestMapping,后者默认匹配所有 HTTP 方法。同时,仍然需要在类级别使用 @RequestMapping 来表达共享映射。
@RequestMapping 不能与在同一元素(类、接口或方法)上声明的其他 @RequestMapping 注解一起使用。如果在同一元素上检测到多个 @RequestMapping 注解,将记录警告,并且只使用第一个映射。这也适用于组合的 @RequestMapping 注解,例如 @GetMapping、@PostMapping 等。 |
以下示例使用类型和方法级别映射:
-
Java
-
Kotlin
@RestController
@RequestMapping("/persons")
class PersonController {
@GetMapping("/{id}")
public Person getPerson(@PathVariable Long id) {
// ...
}
@PostMapping
@ResponseStatus(HttpStatus.CREATED)
public void add(@RequestBody Person person) {
// ...
}
}
@RestController
@RequestMapping("/persons")
class PersonController {
@GetMapping("/{id}")
fun getPerson(@PathVariable id: Long): Person {
// ...
}
@PostMapping
@ResponseStatus(HttpStatus.CREATED)
fun add(@RequestBody person: Person) {
// ...
}
}
URI 模式
您可以使用 glob 模式和通配符映射请求:
| 模式 | 描述 | 示例 |
|---|---|---|
|
字面模式 |
|
|
匹配一个字符 |
|
|
匹配路径段中的零个或多个字符 |
|
|
匹配零个或多个路径段 |
|
|
类似于 |
|
|
将正则表达式 |
|
|
类似于 |
|
捕获的 URI 变量可以通过 @PathVariable 访问,如以下示例所示:
-
Java
-
Kotlin
@GetMapping("/owners/{ownerId}/pets/{petId}")
public Pet findPet(@PathVariable Long ownerId, @PathVariable Long petId) {
// ...
}
@GetMapping("/owners/{ownerId}/pets/{petId}")
fun findPet(@PathVariable ownerId: Long, @PathVariable petId: Long): Pet {
// ...
}
您可以在类和方法级别声明 URI 变量,如以下示例所示:
-
Java
-
Kotlin
@Controller
@RequestMapping("/owners/{ownerId}") (1)
public class OwnerController {
@GetMapping("/pets/{petId}") (2)
public Pet findPet(@PathVariable Long ownerId, @PathVariable Long petId) {
// ...
}
}
| 1 | 类级 URI 映射。 |
| 2 | 方法级 URI 映射。 |
@Controller
@RequestMapping("/owners/{ownerId}") (1)
class OwnerController {
@GetMapping("/pets/{petId}") (2)
fun findPet(@PathVariable ownerId: Long, @PathVariable petId: Long): Pet {
// ...
}
}
| 1 | 类级 URI 映射。 |
| 2 | 方法级 URI 映射。 |
URI 变量会自动转换为适当的类型,否则会引发 TypeMismatchException。默认支持简单类型(int、long、Date 等),您可以注册对任何其他数据类型的支持。请参阅类型转换和DataBinder。
URI 变量可以显式命名(例如,@PathVariable("customId")),但如果名称相同并且您使用 -parameters 编译器标志编译代码,则可以省略该细节。
语法 {*varName} 声明一个 URI 变量,该变量匹配零个或多个剩余的路径段。例如,/resources/{*path} 匹配 /resources/ 下的所有文件,并且 "path" 变量捕获 /resources 下的完整路径。
语法 {varName:regex} 声明一个带有正则表达式的 URI 变量,其语法为:{varName:regex}。例如,给定 URL /spring-web-3.0.5.jar,以下方法提取名称、版本和文件扩展名:
-
Java
-
Kotlin
@GetMapping("/{name:[a-z-]+}-{version:\\d\\.\\d\\.\\d}{ext:\\.[a-z]+}")
public void handle(@PathVariable String version, @PathVariable String ext) {
// ...
}
@GetMapping("/{name:[a-z-]+}-{version:\\d\\.\\d\\.\\d}{ext:\\.[a-z]+}")
fun handle(@PathVariable version: String, @PathVariable ext: String) {
// ...
}
URI 路径模式还可以具有:
-
嵌入式
${…}占位符,它们在启动时通过PropertySourcesPlaceholderConfigurer解析,对照本地、系统、环境和其他属性源。这对于例如根据外部配置参数化基本 URL 非常有用。 -
SpEL 表达式
#{…}。
Spring WebFlux 使用 PathPattern 和 PathPatternParser 来支持 URI 路径匹配。这两个类都位于 spring-web 中,并且专门设计用于 Web 应用程序中的 HTTP URL 路径,其中在运行时匹配大量 URI 路径模式。 |
Spring WebFlux 不支持后缀模式匹配——与 Spring MVC 不同,后者中的 /person 这样的映射也匹配 /person.*。对于基于 URL 的内容协商(如果需要),我们建议使用查询参数,它更简单、更明确,并且更不易受到基于 URL 路径的攻击。
模式比较
当多个模式匹配一个 URL 时,必须对它们进行比较以找到最佳匹配。这是通过 PathPattern.SPECIFICITY_COMPARATOR 完成的,它寻找更具体的模式。
对于每个模式,都会计算一个分数,该分数基于 URI 变量和通配符的数量,其中 URI 变量的分数低于通配符。总分较低的模式获胜。如果两个模式具有相同的分数,则选择较长的模式。
全捕获模式(例如 **、{*varName})被排除在评分之外,并始终排在最后。如果两个模式都是全捕获模式,则选择较长的模式。
可消费的媒体类型
您可以根据请求的 Content-Type 缩小请求映射范围,如以下示例所示:
-
Java
-
Kotlin
@PostMapping(path = "/pets", consumes = "application/json")
public void addPet(@RequestBody Pet pet) {
// ...
}
@PostMapping("/pets", consumes = ["application/json"])
fun addPet(@RequestBody pet: Pet) {
// ...
}
consumes 属性还支持否定表达式——例如,!text/plain 表示除 text/plain 之外的任何内容类型。
您可以在类级别声明共享的 consumes 属性。然而,与大多数其他请求映射属性不同,当在类级别使用时,方法级别的 consumes 属性会覆盖而不是扩展类级别的声明。
MediaType 提供常用媒体类型的常量——例如,APPLICATION_JSON_VALUE 和 APPLICATION_XML_VALUE。 |
可生成的媒体类型
您可以根据 Accept 请求头和控制器方法生成的媒体类型列表缩小请求映射范围,如以下示例所示:
-
Java
-
Kotlin
@GetMapping(path = "/pets/{petId}", produces = "application/json")
@ResponseBody
public Pet getPet(@PathVariable String petId) {
// ...
}
@GetMapping("/pets/{petId}", produces = ["application/json"])
@ResponseBody
fun getPet(@PathVariable petId: String): Pet {
// ...
}
媒体类型可以指定字符集。支持否定表达式——例如,!text/plain 表示除 text/plain 之外的任何内容类型。
您可以在类级别声明共享的 produces 属性。然而,与大多数其他请求映射属性不同,当在类级别使用时,方法级别的 produces 属性会覆盖而不是扩展类级别的声明。
MediaType 提供常用媒体类型的常量——例如,APPLICATION_JSON_VALUE、APPLICATION_XML_VALUE。 |
参数和请求头
您可以根据查询参数条件缩小请求映射范围。您可以测试查询参数是否存在 (myParam),是否存在缺失 (!myParam),或者测试特定值 (myParam=myValue)。以下示例测试带值的参数:
-
Java
-
Kotlin
@GetMapping(path = "/pets/{petId}", params = "myParam=myValue") (1)
public void findPet(@PathVariable String petId) {
// ...
}
| 1 | 检查 myParam 是否等于 myValue。 |
@GetMapping("/pets/{petId}", params = ["myParam=myValue"]) (1)
fun findPet(@PathVariable petId: String) {
// ...
}
| 1 | 检查 myParam 是否等于 myValue。 |
您还可以将相同的条件用于请求头,如以下示例所示:
-
Java
-
Kotlin
@GetMapping(path = "/pets/{petId}", headers = "myHeader=myValue") (1)
public void findPet(@PathVariable String petId) {
// ...
}
| 1 | 检查 myHeader 是否等于 myValue。 |
@GetMapping("/pets/{petId}", headers = ["myHeader=myValue"]) (1)
fun findPet(@PathVariable petId: String) {
// ...
}
| 1 | 检查 myHeader 是否等于 myValue。 |
API 版本
没有标准的方法来指定 API 版本,因此当您在 WebFlux 配置中启用 API 版本控制时,您需要指定如何解析版本。WebFlux 配置会创建一个 ApiVersionStrategy,该策略又用于映射请求。
启用 API 版本控制后,您就可以开始使用版本映射请求了。@RequestMapping 的 version 属性支持以下内容:
-
无值 — 匹配任何版本
-
固定版本("1.2")——仅匹配给定版本
-
基线版本 ("1.2+") — 匹配给定版本及更高版本
如果多个控制器方法具有小于或等于请求版本的版本,则将考虑其中最高且最接近请求版本的那个,实际上会取代其余的。
为了说明这一点,请考虑以下映射:
-
Java
@RestController
@RequestMapping("/account/{id}")
public class AccountController {
@GetMapping (1)
public Account getAccount() {
}
@GetMapping(version = "1.1") (2)
public Account getAccount1_1() {
}
@GetMapping(version = "1.2+") (3)
public Account getAccount1_2() {
}
@GetMapping(version = "1.5") (4)
public Account getAccount1_5() {
}
}
| 1 | 匹配任何版本 |
| 2 | 匹配版本 1.1 |
| 3 | 匹配版本 1.2 及更高版本 |
| 4 | 匹配版本 1.5 |
对于版本 "1.3" 的请求:
-
(1) 匹配,因为它匹配任何版本
-
(2) 不匹配
-
(3) 匹配,因为它匹配 1.2 及更高版本,并被选择为最高匹配
-
(4) 更高且不匹配
对于版本 "1.5" 的请求:
-
(1) 匹配,因为它匹配任何版本
-
(2) 不匹配
-
(3) 匹配,因为它匹配 1.2 及更高版本
-
(4) 匹配,并被选择为最高匹配
版本 "1.6" 的请求没有匹配项。(1) 和 (3) 匹配,但被 (4) 取代,(4) 只允许严格匹配,因此不匹配。在这种情况下,NotAcceptableApiVersionException 会导致 400 响应。
| 以上假设请求版本是“支持”的版本,否则会失败。 |
有关底层基础设施和 API 版本控制支持的更多详细信息,请参阅API 版本控制。
HTTP HEAD、OPTIONS
@GetMapping 和 @RequestMapping(method=HttpMethod.GET) 对于请求映射目的透明地支持 HTTP HEAD。控制器方法无需更改。在 HttpHandler 服务器适配器中应用的响应包装器确保将 Content-Length 头设置为写入的字节数,而无需实际写入响应。
默认情况下,HTTP OPTIONS 通过将 Allow 响应头设置为所有具有匹配 URL 模式的 @RequestMapping 方法中列出的 HTTP 方法列表来处理。
对于没有 HTTP 方法声明的 @RequestMapping,Allow 头设置为 GET,HEAD,POST,PUT,PATCH,DELETE,OPTIONS。控制器方法应始终声明支持的 HTTP 方法(例如,通过使用特定于 HTTP 方法的变体——@GetMapping、@PostMapping 等)。
您可以显式地将 @RequestMapping 方法映射到 HTTP HEAD 和 HTTP OPTIONS,但在常见情况下没有必要。
自定义注解
Spring WebFlux 支持使用组合注解进行请求映射。这些注解本身是用 @RequestMapping 进行元注解的,并组合起来以更窄、更具体的目的重新声明 @RequestMapping 属性的子集(或全部)。
@GetMapping、@PostMapping、@PutMapping、@DeleteMapping 和 @PatchMapping 是组合注解的示例。提供它们是因为,可以说,大多数控制器方法应该映射到特定的 HTTP 方法,而不是使用 @RequestMapping(它默认匹配所有 HTTP 方法)。如果您需要如何实现组合注解的示例,请查看它们的声明方式。
@RequestMapping 不能与在同一元素(类、接口或方法)上声明的其他 @RequestMapping 注解一起使用。如果在同一元素上检测到多个 @RequestMapping 注解,将记录警告,并且只使用第一个映射。这也适用于组合的 @RequestMapping 注解,例如 @GetMapping、@PostMapping 等。 |
Spring WebFlux 还支持带有自定义请求匹配逻辑的自定义请求映射属性。这是一个更高级的选项,需要子类化 RequestMappingHandlerMapping 并覆盖 getCustomMethodCondition 方法,在该方法中您可以检查自定义属性并返回自己的 RequestCondition。
显式注册
您可以以编程方式注册 Handler 方法,这可用于动态注册或高级情况,例如在不同 URL 下使用相同处理程序的多个实例。以下示例显示了如何执行此操作:
-
Java
-
Kotlin
@Configuration
public class MyConfig {
@Autowired
public void setHandlerMapping(RequestMappingHandlerMapping mapping, UserHandler handler) (1)
throws NoSuchMethodException {
RequestMappingInfo info = RequestMappingInfo
.paths("/user/{id}").methods(RequestMethod.GET).build(); (2)
Method method = UserHandler.class.getMethod("getUser", Long.class); (3)
mapping.registerMapping(info, handler, method); (4)
}
}
| 1 | 注入目标处理器和控制器的处理器映射。 |
| 2 | 准备请求映射元数据。 |
| 3 | 获取处理器方法。 |
| 4 | 添加注册。 |
@Configuration
class MyConfig {
@Autowired
fun setHandlerMapping(mapping: RequestMappingHandlerMapping, handler: UserHandler) { (1)
val info = RequestMappingInfo.paths("/user/{id}").methods(RequestMethod.GET).build() (2)
val method = UserHandler::class.java.getMethod("getUser", Long::class.java) (3)
mapping.registerMapping(info, handler, method) (4)
}
}
| 1 | 注入目标处理器和控制器的处理器映射。 |
| 2 | 准备请求映射元数据。 |
| 3 | 获取处理器方法。 |
| 4 | 添加注册。 |
@HttpExchange
虽然 @HttpExchange 的主要目的是用于 带有生成代理的 HTTP 服务客户端,但放置此类注解的 HTTP 服务接口是与客户端与服务器使用无关的契约。除了简化客户端代码之外,在某些情况下,HTTP 服务接口也可能成为服务器为客户端访问公开其 API 的便捷方式。这会导致客户端和服务器之间的耦合增加,通常不是一个好的选择,特别是对于公共 API,但对于内部 API 可能正是目标。这是 Spring Cloud 中常用的一种方法,这也是为什么 @HttpExchange 被支持作为控制器类中服务器端处理的 @RequestMapping 的替代方案。
例如:
-
Java
-
Kotlin
@HttpExchange("/persons")
interface PersonService {
@GetExchange("/{id}")
Person getPerson(@PathVariable Long id);
@PostExchange
void add(@RequestBody Person person);
}
@RestController
class PersonController implements PersonService {
public Person getPerson(@PathVariable Long id) {
// ...
}
@ResponseStatus(HttpStatus.CREATED)
public void add(@RequestBody Person person) {
// ...
}
}
@HttpExchange("/persons")
interface PersonService {
@GetExchange("/{id}")
fun getPerson(@PathVariable id: Long): Person
@PostExchange
fun add(@RequestBody person: Person)
}
@RestController
class PersonController : PersonService {
override fun getPerson(@PathVariable id: Long): Person {
// ...
}
@ResponseStatus(HttpStatus.CREATED)
override fun add(@RequestBody person: Person) {
// ...
}
}
@HttpExchange 和 @RequestMapping 存在差异。@RequestMapping 可以通过路径模式、HTTP 方法等映射任意数量的请求,而 @HttpExchange 声明一个带有具体 HTTP 方法、路径和内容类型的单个端点。
对于方法参数和返回值,通常,@HttpExchange 支持 @RequestMapping 方法参数的子集。值得注意的是,它排除了任何服务器端特定的参数类型。有关详细信息,请参阅 @HttpExchange 和 @RequestMapping 的列表。