Response DTO for output in Spring Boot

Introduction

A Response DTO helps send only the needed data back to users in a clear and simple way.

When you want to send specific data from your server to the client without exposing internal details.

When you want to format the output data differently from how it is stored in the database.

When you want to improve security by hiding sensitive fields from the response.

When you want to keep your API responses consistent and easy to understand.

When you want to add extra information like status messages or timestamps to the response.

Syntax

Spring Boot

public class ResponseDto {
    private String field1;
    private int field2;

    // Constructor
    public ResponseDto(String field1, int field2) {
        this.field1 = field1;
        this.field2 = field2;
    }

    // Getters and setters
    public String getField1() {
        return field1;
    }

    public void setField1(String field1) {
        this.field1 = field1;
    }

    public int getField2() {
        return field2;
    }

    public void setField2(int field2) {
        this.field2 = field2;
    }
}

A Response DTO is a simple Java class with private fields and public getters/setters.

It usually matches the data you want to send back, not the full database entity.

Examples

This DTO sends only username and email to the client, hiding other user details.

Spring Boot

public class UserResponseDto {
    private String username;
    private String email;

    public UserResponseDto(String username, String email) {
        this.username = username;
        this.email = email;
    }

    public String getUsername() {
        return username;
    }

    public String getEmail() {
        return email;
    }
}

Using Java record (Java 17+) makes a simple immutable DTO with less code.

Spring Boot

public record ProductResponseDto(String name, double price) {}

Sample Program

This Spring Boot example shows a Response DTO used in a controller to send a greeting message as JSON.

Spring Boot

package com.example.demo.dto;

public class GreetingResponseDto {
    private String message;

    public GreetingResponseDto(String message) {
        this.message = message;
    }

    public String getMessage() {
        return message;
    }

    public void setMessage(String message) {
        this.message = message;
    }
}

package com.example.demo.controller;

import com.example.demo.dto.GreetingResponseDto;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class GreetingController {

    @GetMapping("/greet")
    public GreetingResponseDto greet() {
        return new GreetingResponseDto("Hello, welcome to our API!");
    }
}

Important Notes

Always keep Response DTOs simple and focused on what the client needs.

Use records in Java 17+ for concise immutable DTOs.

Do not expose sensitive or internal fields in your Response DTO.

Summary

Response DTOs shape the data sent back to clients clearly and safely.

They help separate internal data from what the user sees.

Using Response DTOs improves API design and security.

Practice

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

easy

A. To handle incoming HTTP requests

B. To define the exact data structure sent back to the client

C. To store data in the database

D. To configure application properties

Solution

1. Step 1: Understand the role of Response DTO

   A Response DTO is used to shape the data sent back to the client, controlling what fields are exposed.

2. Step 2: Differentiate from other components

   It is not used for storing data or handling requests, but specifically for output formatting.

3. Final Answer:

   To define the exact data structure sent back to the client -> Option B

4. Quick Check:

   Response DTO = Output data structure [OK]

Hint: Response DTO controls output data format [OK]

Common Mistakes:

• Confusing Response DTO with entity or request DTO
• Thinking Response DTO handles input data
• Assuming Response DTO manages database operations

2. Which of the following is the correct way to define a simple Response DTO class in Spring Boot?

easy

A. public record UserResponse(String name) {}

B. public class UserResponse { private String name; public String getName() { return name; } }

C. public enum UserResponse { NAME; }

D. public interface UserResponse { String name; }

Solution

1. Step 1: Identify valid Java class for DTO

   Spring Boot supports Java records as concise DTOs with immutable fields and automatic getters.

2. Step 2: Check syntax correctness

   public record UserResponse(String name) {} uses a record with a field and no boilerplate code, which is modern and valid.

3. Final Answer:

   public record UserResponse(String name) {} -> Option A

4. Quick Check:

   Use record for simple immutable DTO [OK]

Hint: Use Java record for simple DTOs [OK]

Common Mistakes:

• Using interface instead of class or record
• Using enum for data container
• Omitting getters in POJO classes

3. Given this Response DTO and controller method, what JSON will be returned?

public record ProductResponse(String name, double price) {}

@GetMapping("/product")
public ProductResponse getProduct() {
  return new ProductResponse("Book", 12.5);
}

medium

A. {"name":"Book"}

B. {"productName":"Book","productPrice":12.5}

C. {"name":"Book","price":12.5}

D. {"name":"Book","price":"12.5"}

Solution

1. Step 1: Understand record fields and JSON mapping

   The record fields are name and price, which map directly to JSON keys.

2. Step 2: Check returned JSON structure

   The returned JSON includes both fields with correct types: string for name and number for price.

3. Final Answer:

   {"name":"Book","price":12.5} -> Option C

4. Quick Check:

   Record fields map directly to JSON keys [OK]

Hint: Record fields become JSON keys as-is [OK]

Common Mistakes:

• Assuming JSON keys change names automatically
• Treating numbers as strings in JSON
• Missing fields in output JSON

4. What is wrong with this Response DTO class?

public class UserResponse {
  private String username;
  public UserResponse(String username) {}
  public String getUsername() { return username; }
}

medium

A. Class should be abstract

B. Getter method is missing

C. Field username should be public

D. Constructor does not assign the username field

Solution

1. Step 1: Check constructor implementation

   The constructor has a parameter but does not assign it to the field, so username remains null.

2. Step 2: Verify getter correctness

   The getter returns the field value, but since field is never set, it returns null.

3. Final Answer:

   Constructor does not assign the username field -> Option D

4. Quick Check:

   Constructor must set fields [OK]

Hint: Always assign constructor params to fields [OK]

Common Mistakes:

• Forgetting to assign constructor parameters
• Making fields public unnecessarily
• Thinking getters alone set values

5. You want to create a Response DTO that only exposes a user's id and email, hiding the password. Which approach is best in Spring Boot?

hard

A. Create a separate Response DTO class with only id and email fields

B. Return the User entity directly and ignore the password field

C. Use @JsonIgnore on the password field in the User entity

D. Send the entire User entity and filter password on the client side

Solution

1. Step 1: Understand security and data exposure

   Exposing only needed fields via a Response DTO prevents accidental leaks of sensitive data like passwords.

2. Step 2: Evaluate options for hiding password

   Creating a separate DTO with only safe fields is best practice; relying on @JsonIgnore or client filtering is less secure or less clear.

3. Final Answer:

   Create a separate Response DTO class with only id and email fields -> Option A

4. Quick Check:

   Separate DTOs protect sensitive data [OK]

Hint: Use dedicated DTOs to expose only safe fields [OK]

Common Mistakes:

• Returning entity directly exposing sensitive data
• Relying on client-side filtering for security
• Misusing @JsonIgnore without DTO separation