@PathVariable vs @RequestParam — URL Path vs Query String

Direct Answer

@PathVariable reads a named segment captured by a URI template, while @RequestParam reads a request parameter such as a query-string value. Resource identifiers often belong in paths and collection filters/options often belong in query parameters, but required versus optional is configured independently. Neither annotation provides authorization or validates resource ownership.

Code Example

@RestController
@RequestMapping("/users")
class UserController {

    // PATH VARIABLE — identifies WHICH resource: GET /users/42
    @GetMapping("/{id}")
    public User getById(@PathVariable Long id) {
        return userService.findById(id);
    }

    // REQUEST PARAM — filters/options: GET /users?status=ACTIVE&page=0
    @GetMapping
    public List<User> search(@RequestParam String status,
                             @RequestParam(defaultValue = "0") int page) {
        return userService.findByStatus(status, page);
    }
}

Path = which resource; query = how to filter it. They often combine: GET /users/42/orders?status=PAID.

Common Mistakes & Pitfalls

• Using @RequestParam for IDs: Freshers write @GetMapping("/users") getUserById(@RequestParam Long id), resulting in /users?id=42. This breaks REST conventions. Resource IDs should be in the path: /users/42 with @PathVariable.
• Mixing them incorrectly: Using path variables for filters like /users/ACTIVE/ADMIN instead of /users?status=ACTIVE&role=ADMIN. Path variables force a rigid hierarchy; query params give flexibility.
• Not understanding required defaults: Both annotations require parameters by default, but the failure mode differs — missing path variables return 404, missing query params return 400. Freshers don't anticipate this when designing APIs that should accept optional filters.