Bird
Raised Fist0
Spring Bootframework~5 mins

@Parameter and @Schema annotations in Spring Boot

Choose your learning style10 modes available
Introduction

These annotations help describe API inputs and outputs clearly. They make your API easier to understand and document.

When you want to explain what a method parameter means in your API.
When you want to add details like example values or descriptions to your API fields.
When generating API documentation automatically with tools like Swagger.
When you want to control how your API parameters appear in the docs.
When you want to specify validation or format details for API data.
Syntax
Spring Boot
@Parameter(name = "paramName", description = "Description here", required = true)
@Schema(description = "Field description", example = "exampleValue", required = true)

@Parameter is used on method parameters to describe them.

@Schema is used on model fields or parameters to add details like examples or descriptions.

Examples
This describes the 'id' path variable as a required user ID.
Spring Boot
@Parameter(name = "id", description = "User ID", required = true)
public ResponseEntity<User> getUser(@PathVariable String id) { ... }
This adds a description and example to the 'name' field in the User model.
Spring Boot
public class User {
  @Schema(description = "User's full name", example = "Jane Doe")
  private String name;
}
This describes an optional query parameter 'page' with an example value.
Spring Boot
@Parameter(description = "Page number for pagination", example = "1", required = false)
@RequestParam int page
Sample Program

This Spring Boot controller uses @Parameter to describe the path variable 'id'. The User class uses @Schema to add descriptions and examples to its fields. This helps generate clear API docs.

Spring Boot
import org.springframework.web.bind.annotation.*;
import io.swagger.v3.oas.annotations.Parameter;
import io.swagger.v3.oas.annotations.media.Schema;
import org.springframework.http.ResponseEntity;

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

  @GetMapping("/{id}")
  public ResponseEntity<User> getUser(
    @Parameter(name = "id", description = "The unique ID of the user", required = true)
    @PathVariable String id) {
    User user = new User(id, "Alice Smith");
    return ResponseEntity.ok(user);
  }
}

class User {
  @Schema(description = "User identifier", example = "123")
  private String id;

  @Schema(description = "Full name of the user", example = "Alice Smith")
  private String name;

  public User(String id, String name) {
    this.id = id;
    this.name = name;
  }

  public String getId() { return id; }
  public String getName() { return name; }
}
OutputSuccess
Important Notes

Use @Parameter on controller method parameters to describe API inputs.

Use @Schema on model fields to add detailed info like examples and descriptions.

These annotations improve auto-generated API docs and help others understand your API.

Summary

@Parameter describes API method parameters.

@Schema describes data model fields with examples and descriptions.

Both help create clear, useful API documentation automatically.

Practice

(1/5)
1. What is the main purpose of the @Parameter annotation in Spring Boot APIs?
easy
A. To describe method parameters for API documentation
B. To define database entity fields
C. To configure security roles
D. To handle exceptions globally

Solution

  1. Step 1: Understand the role of @Parameter

    The @Parameter annotation is used to add descriptive information about method parameters in API endpoints.
  2. Step 2: Differentiate from other annotations

    It is not used for database, security, or exception handling but specifically for API documentation clarity.
  3. Final Answer:

    To describe method parameters for API documentation -> Option A
  4. Quick Check:

    @Parameter describes API method parameters = D [OK]
Hint: Remember: @Parameter is for method parameter docs [OK]
Common Mistakes:
  • Confusing @Parameter with @Schema for data models
  • Thinking @Parameter manages security or exceptions
  • Using @Parameter for database field mapping
2. Which of the following is the correct way to add a description to a method parameter using @Parameter?
easy
A. @Parameter(value = "User ID") String userId
B. @Parameter(description = "User ID") String userId
C. @Parameter(desc = "User ID") String userId
D. @Parameter(text = "User ID") String userId

Solution

  1. Step 1: Recall the correct attribute name

    The @Parameter annotation uses the attribute description to add text about the parameter.
  2. Step 2: Verify syntax correctness

    Only @Parameter(description = "User ID") String userId uses description correctly; others use invalid attribute names.
  3. Final Answer:

    @Parameter(description = "User ID") String userId -> Option B
  4. Quick Check:

    @Parameter uses description attribute = A [OK]
Hint: Use description= for @Parameter text, not value or desc [OK]
Common Mistakes:
  • Using 'value' instead of 'description' attribute
  • Using non-existent attributes like 'desc' or 'text'
  • Omitting the attribute name entirely
3. Given the code snippet:
@Parameter(description = "User's age", required = true) int age

What effect does the required = true have in API documentation?
medium
A. Marks the parameter as mandatory in the API docs
B. Sets a default value for the parameter
C. Makes the parameter optional
D. Hides the parameter from the API docs

Solution

  1. Step 1: Understand the required attribute

    The required = true flag indicates that the parameter must be provided by the API caller.
  2. Step 2: Effect on API documentation

    This makes the parameter appear as mandatory in generated API docs, guiding users to supply it.
  3. Final Answer:

    Marks the parameter as mandatory in the API docs -> Option A
  4. Quick Check:

    required=true means mandatory parameter = B [OK]
Hint: required=true means parameter must be provided [OK]
Common Mistakes:
  • Thinking required=true sets default values
  • Assuming it hides the parameter
  • Confusing required=true with optional parameters
4. Identify the error in this usage of @Schema annotation:
@Schema(description = "User's email", required = "true")
private String email;
medium
A. The annotation must be placed on the getter method, not the field
B. The description attribute is missing
C. The required attribute should be a boolean, not a string
D. The email field must be public for @Schema to work

Solution

  1. Step 1: Check attribute types in @Schema

    The required attribute expects a boolean value, not a string.
  2. Step 2: Identify the error in the code

    Using required = "true" is incorrect; it should be required = true without quotes.
  3. Final Answer:

    The required attribute should be a boolean, not a string -> Option C
  4. Quick Check:

    @Schema required must be boolean, not string = C [OK]
Hint: Use true/false without quotes for boolean attributes [OK]
Common Mistakes:
  • Putting boolean values in quotes
  • Assuming @Schema only works on methods
  • Thinking field visibility affects @Schema
5. You want to document a complex API model field that can be null but has a maximum length of 50 characters. Which @Schema annotation usage is correct?
hard
A. @Schema(description = "Optional comment", maxLength = 50, nullable = false) private String comment;
B. @Schema(description = "Optional comment", maxLength = "50", nullable = "true") private String comment;
C. @Schema(description = "Optional comment", maxLength = 50, required = true) private String comment;
D. @Schema(description = "Optional comment", maxLength = 50, nullable = true) private String comment;

Solution

  1. Step 1: Understand attribute types for @Schema

    Attributes like maxLength expect an integer, and nullable expects a boolean.
  2. Step 2: Match requirements with options

    The field can be null, so nullable = true is needed, and maxLength should be 50 as an integer.
  3. Step 3: Eliminate incorrect options

    @Schema(description = "Optional comment", maxLength = "50", nullable = "true") private String comment; uses strings for boolean and integer, which is wrong. @Schema(description = "Optional comment", maxLength = 50, required = true) private String comment; marks it required (not nullable). @Schema(description = "Optional comment", maxLength = 50, nullable = false) private String comment; sets nullable false, disallowing null.
  4. Final Answer:

    @Schema(description = "Optional comment", maxLength = 50, nullable = true) private String comment; -> Option D
  5. Quick Check:

    Use correct types and nullable=true for optional fields = A [OK]
Hint: Use boolean and int types correctly in @Schema attributes [OK]
Common Mistakes:
  • Using strings instead of boolean or int for attributes
  • Confusing nullable and required attributes
  • Setting nullable false when field can be null
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard