What is @RequestMapping in Spring MVC, and how do the shortcuts @GetMapping, @PostMapping, @PutMapping, @DeleteMapping, and @PatchMapping relate to it?
answer
- Shortcut = @RequestMapping + fixed method
- @GetMapping("/x") == @RequestMapping(value,method=GET)
- Class-level base path + method path concatenate
- No method attr = matches ALL verbs
- Since Spring 4.3, composed annotations
basics
~10 s@RequestMapping maps HTTP requests (by URL path and method) to controller methods. @GetMapping, @PostMapping, @PutMapping, @DeleteMapping, and @PatchMapping are shortcuts for @RequestMapping with the HTTP method already fixed (GET, POST, PUT, DELETE, PATCH).
solid answer
~40 s@RequestMapping is the general annotation that binds an incoming HTTP request to a handler method (or a whole controller class) based on attributes like URL path and HTTP method. The five shortcuts are composed annotations, each pre-configured with a specific HTTP method: @GetMapping is @RequestMapping(method = GET), @PostMapping is method = POST, and so on. So @GetMapping("/users") equals @RequestMapping(value = "/users", method = RequestMethod.GET). Prefer the shortcuts on handler methods: they read clearly and prevent accidentally handling the wrong verb. @RequestMapping is still used at class level to define a base path shared by all methods, and for cases the shortcuts don't cover (e.g., mapping several HTTP methods on one handler). Class-level and method-level paths are concatenated into the full mapping.
code
java · 19 lines@RestController
@RequestMapping("/api/users") // class-level base path
public class UserController {
@GetMapping("/{id}") // GET /api/users/{id}
public User get(@PathVariable Long id) { ... }
@PostMapping // POST /api/users
public User create(@RequestBody User u) { ... }
@PutMapping("/{id}") // PUT /api/users/{id}
public User replace(@PathVariable Long id, @RequestBody User u) { ... }
@DeleteMapping("/{id}") // DELETE /api/users/{id}
public void delete(@PathVariable Long id) { ... }
// Equivalent long form of the first handler:
// @RequestMapping(value = "/{id}", method = RequestMethod.GET)
}go deeper
Must know the five shortcuts map to HTTP verbs and that they are @RequestMapping variants.
Should explain path concatenation and that a method-less @RequestMapping matches all verbs.
Explains composed-annotation mechanism and when raw @RequestMapping is still needed.
Frames verb-explicit mappings as an API-safety default and knows the startup registration model.
**What it solves.** In Spring MVC (the servlet-based web framework), a *controller* is a class annotated with `@Controller` or `@RestController` whose methods handle web requests. Spring needs to know *which* method runs for a given HTTP request. `@RequestMapping` is that mapping declaration; the `RequestMappingHandlerMapping` bean scans controllers at startup and builds a registry from these annotations. **`@RequestMapping` placement.** It can go on a class and/or on a method. A class-level `@RequestMapping("/api/users")` defines a *base path*; each method's mapping is appended to it. So class `/api/users` + method `@GetMapping("/{id}")` yields `GET /api/users/{id}`. **Key attributes.** - `path` (alias `value`): one or more URL patterns, e.g. `"/users"`, `"/users/{id}"`. - `method`: which HTTP verb(s) via the `RequestMethod` enum (GET, POST, PUT, DELETE, PATCH, HEAD, OPTIONS, TRACE). - `params`, `headers`: additional request predicates (must-have query params / headers). - `consumes`: restrict by the request's `Content-Type`. - `produces`: restrict by the client's `Accept` header and set the response content type. **The shortcuts.** `@GetMapping`, `@PostMapping`, `@PutMapping`, `@DeleteMapping`, `@PatchMapping` are *composed annotations* (meta-annotated with `@RequestMapping`) introduced in Spring 4.3. Each hard-wires `method` to one verb and exposes the same `path/params/headers/consumes/produces` attributes (but NOT `method`, which is fixed). They exist only for method-level handlers; there is no `@GetMapping` for a whole class. **Why prefer shortcuts.** They are self-documenting (the verb is visible at a glance) and eliminate a whole class of bugs where a handler unintentionally accepts every verb. A bare `@RequestMapping("/users")` with no `method` matches GET, POST, PUT, DELETE, etc. all at once — rarely what you want for a REST endpoint. **Gotchas.** - `@RequestMapping` with no `method` matches all HTTP methods — a common source of accidental exposure. - The shortcuts cannot set `method` (it's fixed); to map two verbs to one method you must use `@RequestMapping(method = {GET, HEAD})`. - Only one handler may match a request; ambiguous mappings throw `IllegalStateException` at startup or produce a 500 at runtime. - `@RestController` = `@Controller` + `@ResponseBody`; it changes serialization, not the mapping semantics. **When to use which.** Use the verb shortcuts for normal REST handlers. Reserve raw `@RequestMapping` for class-level base paths and the rare multi-verb handler.
- What HTTP methods does a bare @RequestMapping("/users") with no method attribute match?All of them (GET, POST, PUT, DELETE, PATCH, etc.). Without a method predicate the mapping matches every HTTP verb for that path, which is usually a bug — one reason to prefer the verb-specific shortcuts.
- Can you put @GetMapping on the controller class instead of @RequestMapping?No. The verb shortcuts are only meaningful on handler methods. Class-level mappings use @RequestMapping to define a shared base path; the class doesn't handle a single verb.
saying these in an interview costs you the question
- Thinking @GetMapping and @RequestMapping are unrelated separate mechanisms
- Believing @RequestMapping without a method only matches GET
- Claiming class-level and method-level paths override rather than concatenate
- Saying there is a class-level @GetMapping