Request DTO for input in Spring Boot - Performance & Optimization

Performance: Request DTO for input

MEDIUM IMPACT

This affects the server-side processing speed and memory usage during HTTP request handling.

Handling user input in a Spring Boot REST API

Spring Boot

public record UserRequestDTO(String name, int age) {}

@PostMapping("/users")
public ResponseEntity<String> createUser(@RequestBody UserRequestDTO userRequest) {
    // process input
}

Using a single Request DTO consolidates input parsing and validation, reducing overhead and improving maintainability.

📈 Performance GainSingle JSON parse operation and centralized validation reduces CPU usage and potential bugs.

Handling user input in a Spring Boot REST API

Spring Boot

public ResponseEntity<String> createUser(@RequestParam String name, @RequestParam int age) {
    // process input
}

Using multiple @RequestParam for many inputs causes scattered parsing and validation logic, increasing complexity and CPU usage.

📉 Performance CostTriggers multiple parameter parsing steps and scattered validation, increasing CPU cycles and potential errors.

Performance Comparison

Pattern	Parsing Steps	Validation Complexity	CPU Usage	Verdict
Multiple @RequestParam	Multiple separate parses	Scattered validation	Higher CPU usage	[X] Bad
Single Request DTO	Single JSON parse	Centralized validation	Lower CPU usage	[OK] Good

Rendering Pipeline

Request DTOs impact the server's request parsing and validation stages before business logic execution.

→Request Parsing

→Validation

→Business Logic Execution

⚠️ BottleneckRequest Parsing and Validation can become bottlenecks if input is fragmented or poorly structured.

Optimization Tips

1Use a single Request DTO to group related input fields.

2Add validation annotations on DTO fields to catch errors early.

3Avoid multiple scattered @RequestParam annotations for complex inputs.

Performance Quiz - 3 Questions

Why is using a Request DTO better for performance than multiple @RequestParam annotations?

A It increases the number of parsing steps for better accuracy.

B It delays validation until after business logic runs.

C It consolidates parsing into a single step, reducing CPU overhead.

D It requires more memory but improves network speed.

DevTools: Spring Boot Actuator / Application Logs

How to check: Enable debug logging for request handling and validation. Monitor CPU usage and request processing time.

What to look for: Look for reduced parsing time and fewer validation errors when using Request DTOs.

Practice

1. What is the main purpose of a Request DTO in a Spring Boot application?

easy

A. To configure the application server settings

B. To store data directly in the database

C. To handle HTTP responses sent to the client

D. To organize and validate user input separately from database models

Solution

1. Step 1: Understand what a Request DTO is

   A Request DTO (Data Transfer Object) is used to receive and organize input data from users in a clean way.

2. Step 2: Differentiate from other components

   Unlike database models, Request DTOs focus only on input validation and structure, not on storing data.

3. Final Answer:

   To organize and validate user input separately from database models -> Option D

4. Quick Check:

   Request DTO = Input organization and validation [OK]

Hint: Request DTOs separate input from database models [OK]

Common Mistakes:

• Confusing DTO with database entity
• Thinking DTO handles HTTP responses
• Assuming DTO configures server

2. Which of the following is the correct way to declare a simple Request DTO class in Spring Boot to receive a user's name and age?

easy

A. public interface UserRequest { String getName(); int getAge(); }

B. public class UserRequest { private String name; private int age; public String getName() { return name; } public void setName(String name) { this.name = name; } public int getAge() { return age; } public void setAge(int age) { this.age = age; } }

C. @Entity public class UserRequest { private String name; private int age; }

D. @Controller public class UserRequest { private String name; private int age; }

Solution

1. Step 1: Identify the correct DTO structure

   A Request DTO is a simple Java class with private fields and public getters/setters to hold input data.

2. Step 2: Check annotations and class type

   It should NOT be an entity or controller; those are for database and web layers respectively.

3. Final Answer:

   Plain Java class with private fields and getters/setters -> Option B

4. Quick Check:

   DTO = Plain class with getters/setters [OK]

Hint: DTOs are plain classes, not entities or controllers [OK]

Common Mistakes:

• Using @Entity annotation on DTO
• Making DTO an interface
• Annotating DTO as @Controller

3. Given the following Request DTO and controller method, what will be the output if the JSON input is {"name":"Alice","age":30}?

public class UserRequest {
  private String name;
  private int age;
  public String getName() { return name; }
  public void setName(String name) { this.name = name; }
  public int getAge() { return age; }
  public void setAge(int age) { this.age = age; }
}

@PostMapping("/user")
public String createUser(@RequestBody UserRequest request) {
  return "User: " + request.getName() + ", Age: " + request.getAge();
}

medium

A. User: null, Age: 0

B. Compilation error due to missing annotations

C. User: Alice, Age: 30

D. Runtime error due to invalid JSON

Solution

1. Step 1: Understand JSON to DTO mapping

   The JSON keys match the DTO fields, so Spring Boot maps "name" to name and "age" to age correctly.

2. Step 2: Check controller return value

   The method returns a string combining name and age from the DTO, so it outputs "User: Alice, Age: 30".

3. Final Answer:

   User: Alice, Age: 30 -> Option C

4. Quick Check:

   Matching JSON fields produce correct output [OK]

Hint: Matching JSON keys to DTO fields maps input correctly [OK]

Common Mistakes:

• Assuming missing annotations cause errors
• Expecting null values despite matching JSON
• Confusing runtime errors with mapping

4. Identify the error in this Request DTO class that causes Spring Boot to fail binding JSON input:

public class ProductRequest {
  private String productName;
  private int quantity;
  public int getQuantity() { return quantity; }
  public void setQuantity(int quantity) { this.quantity = quantity; }
}

medium

A. Missing getter and setter for productName field

B. Quantity field should be public

C. Class must be annotated with @RequestBody

D. No default constructor defined

Solution

1. Step 1: Check field access and methods

   productName lacks getter/setter, so Spring cannot bind JSON to it properly.

2. Step 2: Validate other options

   Quantity has proper getter/setter; @RequestBody is for method parameters, not classes; default constructor is implicit.

3. Final Answer:

   Missing getter and setter for productName field -> Option A

4. Quick Check:

   DTO fields need getters/setters for binding [OK]

Hint: DTO fields need getters/setters for JSON binding [OK]

Common Mistakes:

• Thinking public fields bind without getters/setters
• Adding @RequestBody on DTO class
• Assuming default constructor must be explicit

5. You want to ensure that the email field in your Request DTO is not empty and follows a valid email format. Which annotations should you add to the email field to achieve this validation automatically in Spring Boot?

hard

A. @NotEmpty and @Email

B. @Valid and @NotNull

C. @Size(min=1) and @Pattern(regexp=".+@.+\\..+")

D. @NotBlank and @JsonProperty

Solution

1. Step 1: Identify validation annotations for non-empty and email format

   @NotEmpty ensures the field is not empty, and @Email checks for valid email format.

2. Step 2: Evaluate other options

   @Valid is for nested validation, @NotNull allows empty strings, @Size and @Pattern can work but are more complex; @JsonProperty is for JSON mapping, not validation.

3. Final Answer:

   @NotEmpty and @Email -> Option A

4. Quick Check:

   Use @NotEmpty and @Email for email validation [OK]

Hint: Use @NotEmpty and @Email for email validation [OK]

Common Mistakes:

• Using @NotNull which allows empty strings
• Confusing @Valid with validation annotations
• Using @JsonProperty for validation