Annotations Cheat Sheet
This quick reference collects the annotations and properties you reach for daily so you don't have to search documentation mid-task. @RestController combines @Controller and @ResponseBody so return values are serialized straight to the HTTP response body as JSON via Jackson, while @RequestMapping and its shortcuts (@GetMapping, @PostMapping, @PutMapping, @DeleteMapping, @PatchMapping) map HTTP verbs and paths to handler methods, with @PathVariable extracting URI template segments and @RequestParam extracting query parameters.
Cricket analogy: Keeping this cheat sheet handy is like a scorer keeping a quick-reference card of extras rules (wide, no-ball, bye) rather than re-reading the entire laws of cricket mid-match.
@RestController
@RequestMapping("/api/v1/orders")
public class OrderController {
@GetMapping("/{id}")
public OrderDto getOrder(@PathVariable Long id) { ... }
@GetMapping
public List<OrderDto> search(@RequestParam(required = false) String status) { ... }
@PostMapping
@ResponseStatus(HttpStatus.CREATED)
public OrderDto create(@Valid @RequestBody CreateOrderRequest request) { ... }
}Configuration Properties and Profiles
application.yml (or .properties) holds environment-specific settings, and spring.config.activate.on-profile lets you define profile-specific overrides in the same file using --- document separators, activated at runtime via SPRING_PROFILES_ACTIVE=prod or --spring.profiles.active=prod. For typed, IDE-autocompleted access to custom properties, @ConfigurationProperties(prefix = "app.mail") on a class annotated @Component (or registered via @EnableConfigurationProperties) binds nested YAML structures directly to Java fields, which is safer and more testable than scattering @Value("${...}") expressions throughout the codebase.
Cricket analogy: Profile-specific configuration is like a team having different pitch-reading strategies pre-saved for a spin-friendly Chennai pitch versus a pace-friendly Perth pitch, switched based on the venue.
spring:
application:
name: order-service
datasource:
url: jdbc:postgresql://localhost:5432/orders
---
spring:
config:
activate:
on-profile: prod
datasource:
url: jdbc:postgresql://prod-db:5432/orders
logging:
level:
root: WARNActuator Endpoints and Common CLI Commands
spring-boot-starter-actuator exposes operational endpoints under /actuator once enabled and whitelisted via management.endpoints.web.exposure.include; the ones you'll reach for constantly are /actuator/health (liveness/readiness, aggregating custom HealthIndicator beans), /actuator/metrics (JVM, HTTP, and custom Micrometer metrics), /actuator/env (resolved property sources, useful for debugging why a property isn't taking effect), and /actuator/loggers (which lets you change a package's log level at runtime via a POST request without redeploying). On the build side, the Maven wrapper (./mvnw spring-boot:run) or Gradle wrapper (./gradlew bootRun) runs the app locally, ./mvnw clean package produces the deployable JAR, and ./mvnw spring-boot:build-image builds a container image directly.
Cricket analogy: Actuator endpoints are like a team's live vitals dashboard during a match — heart rate, hydration, sprint speed — giving instant operational insight without stopping play to ask each player individually.
management.endpoints.web.exposure.include=health,info,metrics,prometheus is a common baseline; never set it to * in production without also securing Actuator endpoints, since some (like /actuator/env or /actuator/heapdump) can leak secrets or memory contents.
Forgetting to secure Actuator endpoints separately from your main API's security rules is a frequent production incident — by default, once exposed, Actuator endpoints are reachable at the same base URL and port unless you explicitly restrict access with Spring Security rules or a separate management port.
- @RestController + @GetMapping/@PostMapping/etc. is the standard combination for JSON REST endpoints.
- @PathVariable reads URI template segments; @RequestParam reads query string parameters.
- Use --- document separators with spring.config.activate.on-profile for profile-specific YAML overrides.
- @ConfigurationProperties gives typed, IDE-friendly binding of nested config, preferable to scattered @Value expressions.
- Actuator's /actuator/health, /actuator/metrics, /actuator/env, and /actuator/loggers are the most frequently used endpoints.
- ./mvnw spring-boot:run / ./gradlew bootRun runs locally; clean package builds the JAR; spring-boot:build-image builds a container.
- Never expose all Actuator endpoints (management.endpoints.web.exposure.include=*) in production without separately securing them.
Practice what you learned
1. What does @RestController do that plain @Controller does not?
2. How do you define profile-specific overrides within a single application.yml file?
3. What is the advantage of @ConfigurationProperties over scattered @Value annotations?
4. Which Actuator endpoint lets you change a package's log level at runtime without redeploying?
Was this page helpful?
You May Also Like
Spring Boot Interview Questions
A curated walkthrough of the Spring Boot interview questions that come up most often, from auto-configuration internals to system-design judgment calls.
Testing Spring Boot Applications
A practical guide to layering unit, slice, and integration tests in Spring Boot using JUnit 5, Mockito, MockMvc, and Testcontainers.
Spring Boot with Docker
How to containerize Spring Boot applications using Dockerfiles, layered JARs, Cloud Native Buildpacks, and Docker Compose for local development.
Related Reading
Related Study Notes in Web Development
Browse all study notesWebSockets Study Notes
Web Development · 30 topics
Web DevelopmentWebAssembly Study Notes
WebAssembly · 30 topics
Web DevelopmentgRPC Study Notes
Protocol Buffers · 30 topics
Web DevelopmentFlask Study Notes
Python · 30 topics
Web DevelopmentDjango Study Notes
Python · 30 topics
Web DevelopmentNext.js Study Notes
JavaScript · 30 topics