항해99 47일차 TIL1 - API 개발 시 엔티티 대신 DTO를 노출시켜라.

제목 그대로입니다. 그 이유는 아래와 같습니다.

 

1. API 스펙 변경 가능성

2. 필요없는 데이터가 넘겨질 가능성

 

 

1. API 스펙 변경 가능성

가정을 해봅시다. 프론트앤드 개발자분께서 아래와 같이 데이터를 받고 싶다고 요청한다고 합시다.

// JSON
{
username : "자몽",
}
,
{
username : "포도",
}
...

 

현재 엔티티는 아래와 같습니다.

public class Member {

    @Id @GeneratedValue
    @Column(name = "member_id")
    private Long id;

    private String name;
    private Integer age;

 

만약 엔티티를 반환하면서 프론트앤드 개발자분의 요구사항을 수행하려면 필드 명 name 에서 username으로 변경해야 합니다. 우선 기본적으로 DB에서 쿼리 오류가 발생할 확률이 높겠죠. 해결했다고 쳐도 기존에 존재했던 Member 엔티티와 연관있는 모든 API에서 오류가 날 것입니다.

 

왜냐하면 기존 API 스펙에서는 username 대신 name을 사용하기 때문이죠.

// JSON
{
name : "자몽",
age : 27
}

 

 FE 개발자분들은 name 을 통해 유저의 네임을 요청했을 것입니다. 1번 만으로도 컨트롤러에서 엔티티를 반환하는 것은 엄청난 한계를 지닙니다.

 

2. 필요없는 데이터가 넘겨질 가능성

에플리케이션 사용자(Member)의 username을 조회하는 요구사항이 들어왔습니다. 엔드포인트에서 엔티티를 반환한다면 username 외에 엔티티에 포함된 모든 데이터가 넘겨지게 됩니다.

응답 결과

 

문제를 해결하는 방법은 DTO를 사용하는 것입니다.

// dto
@Getter
public class MemberResponse {
    private String username;

    public MemberResponse(String username) {
        this.username = username;
    }
}

// controller
@GetMapping("/api/v4/members")
public List<MemberResponse> membersV4() {
    return memberService.findMembers().stream()
            .map(member -> new MemberResponse(member.getName()))
            .collect(Collectors.toList());
}

 

응답 결과

 

여기서 한 걸음 더 나아가면 리스트를 객체로 한 번 감싸주는 것이 좋습니다. 그 이유는 response에 유연성을 더하기 위함입니다. 추후 TIL에서 따로 다루도록 하겠습니다.