The Pattern That Powers Enterprise REST APIs
Spring Boot controllers route HTTP requests through four input mechanisms. If you're architecting microservices in APAC—where Spring holds 35% of the Java backend market—you've used these. The question is whether you're using them consistently.
@PathVariable pulls data from URL paths. Use it for resource identifiers: /users/{id} or /orders/{orderId}. It's part of the URL structure, making it visible in logs and browser history. Performance is identical to other annotations—the choice is architectural, not technical.
@RequestParam extracts query strings: /products?category=electronics&minPrice=1000. This is your filtering and pagination tool. Unlike path variables, these are optional by default. Set required = false and provide defaultValue to avoid null handling downstream.
@RequestBody handles POST and PUT payloads. This is where JSON validation matters—combine it with @Valid and Jakarta validation annotations. Complex data structures belong here, not in query strings that hit URL length limits (typically 2KB in production load balancers).
@RequestHeader reads HTTP headers. Authentication tokens, API keys, correlation IDs for distributed tracing. If you're not validating header presence, you're creating silent failure modes.
Trade-offs Worth Noting
Path variables and request params appear in access logs. Request bodies don't. That matters for debugging and security auditing. Headers are invisible to users but visible to infrastructure—your load balancer sees them, your CDN caches against them.
Some teams favor Micronaut or Quarkus for lower memory footprint (~50% reduction reported in high-scale deployments). Spring Boot's auto-configuration convenience has costs. But for most enterprise APAC applications—68% of Spring projects use these REST patterns—the productivity gain outweighs the resource overhead.
What This Means in Practice
Consistent input patterns make APIs predictable. Document which pattern you use where and why. Code reviews catch deviations. The technical debt isn't in choosing Spring Boot—it's in mixing these patterns inconsistently across teams.
History suggests framework debates matter less than implementation discipline. Spring Boot's 15% year-over-year growth indicates enterprises aren't switching away. They're standardizing on patterns that work.