Mastering SpringBoot Path Variables: Regex, Placeholders, and Suffix Matching
This guide explains how to use regular‑expression path variables, property placeholders, class‑level parameters, and suffix‑based content negotiation in SpringBoot 3.2.5, providing code examples, configuration tips, and practical request illustrations for flexible URL routing.
Environment: SpringBoot 3.2.5
1. Regular‑Expression Path Variables
Controller mapping can use {varName:regex} to capture parts of the URL and pass them as method parameters, increasing routing flexibility.
<code>@GetMapping("/{name:[a-z-]+}-{version:\\d\\.\\d\\.\\d}{ext:\\.[a-z]+}")
public Object p1(@PathVariable String name, @PathVariable String version, @PathVariable String ext) {
return String.format("%s-%s%s", name, version, ext);
}</code>name matches one or more lowercase letters or hyphens ( [a-z-]+ ); version matches three numbers separated by dots ( \\d\\.\\d\\.\\d ); ext matches a dot followed by one or more lowercase letters ( \\.[a-z]+ ).
2. URI Placeholder (${...})
URI patterns can embed ${...} placeholders that are resolved at startup using PropertySourcesPlaceholderConfigurer . This allows external configuration of base URLs.
<code>@GetMapping("${pack.uri}")
public Object uri() {
// TODO
return "uri";
}</code>Define the placeholder in application.yml :
<code>pack:
uri: /xxxooo</code>Combination with a static prefix:
<code>@GetMapping("/api${pack.uri}")
public Object uri() { }</code>SpEL expression can also be used:
<code>@GetMapping("/api${pack.uri}/#{1+2}")
public Object uri() { }</code>3. Class‑Level Path Parameter
<code>@RestController
@RequestMapping("/users/{type}")
public class PathController {
@GetMapping("/single/{id}")
public Object p1(@PathVariable Integer type, @PathVariable Long id) {
return DATAS.stream()
.filter(u -> type == u.getType() && id == u.getId())
.collect(Collectors.toList());
}
}</code>The {type} variable is defined at the class level and can be accessed directly in method parameters.
4. Suffix Matching and Content Negotiation
Since Spring MVC 5.3, path patterns ending with .* are no longer matched by default, and the path extension is not used to determine the response media type. The feature was deprecated in 5.2.4 and removed in later versions.
For older versions you can enable it via configuration:
<code>spring:
mvc:
contentnegotiation:
favor-path-extension: true</code>Or programmatically in Spring 6.x:
<code>@Component
public class PathWebMvcConfigurer implements WebMvcConfigurer {
@Override
public void configureContentNegotiation(ContentNegotiationConfigurer configurer) {
// Enable path‑extension based negotiation
configurer.favorPathExtension(true);
}
}</code>Example endpoint using suffix pattern:
<code>@GetMapping("/{id}/fmt.*")
public Object p1(@PathVariable Long id) {
return DATAS.stream()
.filter(u -> id == u.getId())
.collect(Collectors.toList());
}</code>When the request ends with .json , the response is JSON; for .xml you need the Jackson XML module:
<code><dependency>
<groupId>com.fasterxml.jackson.dataformat</groupId>
<artifactId>jackson-dataformat-xml</artifactId>
</dependency></code>After adding the dependency, Spring automatically registers an XML message converter. Custom formats require implementing a custom HttpMessageConverter .
Spring Full-Stack Practical Cases
Full-stack Java development with Vue 2/3 front-end suite; hands-on examples and source code analysis for Spring, Spring Boot 2/3, and Spring Cloud.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.