映射请求
本节讨论用于注解控制器的请求映射。
@RequestMapping
@RequestMapping
注解用于将请求映射到控制器方法。它具有各种属性,可以按 URL、HTTP 方法、请求参数、请求头和媒体类型进行匹配。您可以在类级别使用它来表达共享映射,也可以在方法级别使用它来缩小到特定的端点映射。
还有 HTTP 方法特定的 @RequestMapping
快捷变体:
-
@GetMapping
-
@PostMapping
-
@PutMapping
-
@DeleteMapping
-
@PatchMapping
上述注解是 自定义注解,它们之所以提供,是因为可以说,大多数控制器方法应该映射到特定的 HTTP 方法,而不是使用 @RequestMapping
(默认情况下,它匹配所有 HTTP 方法)。同时,仍然需要在类级别使用 @RequestMapping
来表达共享映射。
|
以下示例使用类型和方法级别映射:
-
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 模式和通配符映射请求:
模式 | 描述 | 示例 |
---|---|---|
|
匹配一个字符 |
|
|
匹配路径段内的零个或多个字符 |
|
|
匹配路径末尾的零个或多个路径段 |
|
|
匹配一个路径段并将其捕获为名为 "name" 的变量 |
|
|
匹配正则表达式 |
|
|
匹配路径末尾的零个或多个路径段并将其捕获为名为 "path" 的变量 |
|
捕获的 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
-
@Controller @RequestMapping("/owners/{ownerId}") [id="CO1-1"][id="CO1-1"][id="CO1-1"](1) public class OwnerController { @GetMapping("/pets/{petId}") [id="CO1-2"][id="CO1-2"][id="CO1-2"](2) public Pet findPet(@PathVariable Long ownerId, @PathVariable Long petId) { // ... } }
<1> 类级别 URI 映射。 <1> 方法级别 URI 映射。
- Kotlin
-
@Controller @RequestMapping("/owners/{ownerId}") [id="CO2-1"][id="CO1-3"][id="CO2-1"](1) class OwnerController { @GetMapping("/pets/{petId}") [id="CO2-2"][id="CO1-4"][id="CO2-2"](2) fun findPet(@PathVariable ownerId: Long, @PathVariable petId: Long): Pet { // ... } }
<1> 类级别 URI 映射。 <1> 方法级别 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 使用 |
Spring WebFlux 不支持后缀模式匹配——与 Spring MVC 不同,在 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
属性会覆盖而不是扩展类级别的声明。
|
可生成媒体类型
您可以根据 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
属性会覆盖而不是扩展类级别的声明。
|
参数和请求头
您可以根据查询参数条件缩小请求映射范围。您可以测试查询参数的存在(myParam
)、不存在(!myParam
)或特定值(myParam=myValue
)。以下示例测试具有值的参数:
- Java
-
@GetMapping(path = "/pets/{petId}", params = "myParam=myValue") [id="CO3-1"][id="CO1-5"][id="CO3-1"](1) public void findPet(@PathVariable String petId) { // ... }
<1> 检查 `myParam` 是否等于 `myValue`。
- Kotlin
-
@GetMapping("/pets/{petId}", params = ["myParam=myValue"]) [id="CO4-1"][id="CO1-6"][id="CO4-1"](1) fun findPet(@PathVariable petId: String) { // ... }
<1> 检查 `myParam` 是否等于 `myValue`。
您也可以对请求头条件使用相同的方法,如以下示例所示:
- Java
-
@GetMapping(path = "/pets/{petId}", headers = "myHeader=myValue") [id="CO5-1"][id="CO1-7"][id="CO5-1"](1) public void findPet(@PathVariable String petId) { // ... }
<1> 检查 `myHeader` 是否等于 `myValue`。
- Kotlin
-
@GetMapping("/pets/{petId}", headers = ["myHeader=myValue"]) [id="CO6-1"][id="CO1-8"][id="CO6-1"](1) fun findPet(@PathVariable petId: String) { // ... }
<1> 检查 `myHeader` 是否等于 `myValue`。
HTTP HEAD, OPTIONS
@GetMapping
和 @RequestMapping(method=HttpMethod.GET)
为请求映射目的透明地支持 HTTP HEAD。控制器方法无需更改。在 HttpHandler
服务器适配器中应用的响应包装器确保 Content-Length
头设置为写入的字节数,而无需实际写入响应。
默认情况下,HTTP OPTIONS 通过将 Allow
响应头设置为所有 @RequestMapping
方法中列出的 HTTP 方法列表来处理,这些方法具有匹配的 URL 模式。
对于没有 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 方法)。如果您需要一个如何实现组合注解的示例,请查看这些注解的声明方式。
|
Spring WebFlux 还支持带有自定义请求匹配逻辑的自定义请求映射属性。这是一个更高级的选项,需要子类化 RequestMappingHandlerMapping
并覆盖 getCustomMethodCondition
方法,您可以在其中检查自定义属性并返回自己的 RequestCondition
。
显式注册
您可以编程方式注册 Handler 方法,这可用于动态注册或用于高级情况,例如在不同 URL 下使用相同处理程序的各种实例。以下示例展示了如何执行此操作:
- Java
-
@Configuration public class MyConfig { @Autowired public void setHandlerMapping(RequestMappingHandlerMapping mapping, UserHandler handler) [id="CO7-1"][id="CO1-9"][id="CO7-1"](1) throws NoSuchMethodException { RequestMappingInfo info = RequestMappingInfo .paths("/user/{id}").methods(RequestMethod.GET).build(); [id="CO7-2"][id="CO1-10"][id="CO7-2"](2) Method method = UserHandler.class.getMethod("getUser", Long.class); [id="CO7-3"][id="CO1-11"][id="CO7-3"](3) mapping.registerMapping(info, handler, method); [id="CO7-4"][id="CO1-12"][id="CO7-4"](4) } }
<1> 注入目标处理程序和控制器处理程序映射。 <1> 准备请求映射元数据。 <1> 获取处理程序方法。 <1> 添加注册。
- Kotlin
-
@Configuration class MyConfig { @Autowired fun setHandlerMapping(mapping: RequestMappingHandlerMapping, handler: UserHandler) { [id="CO8-1"][id="CO1-13"][id="CO8-1"](1) val info = RequestMappingInfo.paths("/user/{id}").methods(RequestMethod.GET).build() [id="CO8-2"][id="CO1-14"][id="CO8-2"](2) val method = UserHandler::class.java.getMethod("getUser", Long::class.java) [id="CO8-3"][id="CO1-15"][id="CO8-3"](3) mapping.registerMapping(info, handler, method) [id="CO8-4"][id="CO1-16"][id="CO8-4"](4) } }
<1> 注入目标处理程序和控制器处理程序映射。 <1> 准备请求映射元数据。 <1> 获取处理程序方法。 <1> 添加注册。
@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 的列表。