API 개발 기본 - Entity와 DTO

회원 등록 API

 

V1 엔티티를 Request Body에 직접 매핑

package jpabook.jpashop.api;
 import jpabook.jpashop.domain.Member;
 import jpabook.jpashop.service.MemberService;
 import lombok.AllArgsConstructor;
 import lombok.Data;
 import lombok.RequiredArgsConstructor;
 import org.springframework.web.bind.annotation.*;
 import javax.validation.Valid;
 import java.util.List;
 import java.util.stream.Collectors;
 @RestController
 @RequiredArgsConstructor
 public class MemberApiController {
     private final MemberService memberService;
     
     
	/**
	* 등록 V1: 요청 값으로 Member 엔티티를 직접 받는다.
	* 문제점
	* - 엔티티에 프레젠테이션 계층을 위한 로직이 추가된다.
	* - 엔티티에 API 검증을 위한 로직이 들어간다. (@NotEmpty 등등)
	* - 실무에서는 회원 엔티티를 위한 API가 다양하게 만들어지는데, 한 엔티티에 각각의 API를 위한
	모든 요청 요구사항을 담기는 어렵다.
	* - 엔티티가 변경되면 API 스펙이 변한다.
	* 결론
	* - API 요청 스펙에 맞추어 별도의 DTO를 파라미터로 받는다. */
     @PostMapping("/api/v1/members")
     public CreateMemberResponse saveMemberV1(@RequestBody @Valid Member member){
         Long id = memberService.join(member);
         return new CreateMemberResponse(id);
     }
     @Data
     static class CreateMemberRequest {
         private String name;
     }
     
     @Data
     static class CreateMemberResponse {
         private Long id;
         public CreateMemberResponse(Long id) {
             this.id = id;
		} 
	}
}

문제점

• 엔티티에 프레젠테이션 계층을 위한 로직이 추가됨
• 엔티티에 API 검증을 위한 로직이 들어감 (@NotEmpty 등등)
• 실무에서는 회원 엔티티를 위한 API가 다양하게 만들어지는데, 한 엔티티에 각각의 API를 위한 모든 요청 요구사항을 담기는 어려움
• 엔티티가 변경되면 API 스펙이 변함

결론 : API 요청 스펙에 맞추어 별도의 DTO 파라미터로 받음

 

 

 

V2 엔티티 대신에 DTO를 RequestBody에 매핑

	/**
	* 등록 V2: 요청 값으로 Member 엔티티 대신에 별도의 DTO를 받는다. */
     @PostMapping("/api/v2/members")
     public CreateMemberResponse saveMemberV2(@RequestBody @Valid
 	CreateMemberRequest request) {

     Member member = new Member();
     member.setName(request.getName());
     Long id = memberService.join(member);
     return new CreateMemberResponse(id);
 }

• CreateMemberRequest를 Member 엔티티 대신에 RequestBody와 매핑
• 엔티티와 프레젠테이션 계층을 위한 로직을 분리할 수 있음
• 엔티티와 API 스펙을 명확히 분리 가능
• 엔티티가 변해도 API 스펙이 변하지 않음

참고) 실무에서는 엔티티를 API 스펙에 노출하면 안된다!!

 

 

회원 조회 API

 

 

V1 응답 값으로 엔티티를 직접 외부에 노출

package jpabook.jpashop.api;
 @RestController
 @RequiredArgsConstructor
 public class MemberApiController {
     private final MemberService memberService;
	/**
	* 조회 V1: 응답 값으로 엔티티를 직접 외부에 노출한다.
	* 문제점
	* - 엔티티에 프레젠테이션 계층을 위한 로직이 추가된다.
	* - 기본적으로 엔티티의 모든 값이 노출된다.
	* - 응답 스펙을 맞추기 위해 로직이 추가된다. (@JsonIgnore, 별도의 뷰 로직 등등)
	* - 실무에서는 같은 엔티티에 대해 API가 용도에 따라 다양하게 만들어지는데, 한 엔티티에 각각의
	API를 위한 프레젠테이션 응답 로직을 담기는 어렵다.
	* - 엔티티가 변경되면 API 스펙이 변한다.
	* - 추가로 컬렉션을 직접 반환하면 항후 API 스펙을 변경하기 어렵다.(별도의 Result 클래스 생성으
	로 해결)
	* 결론
	* - API 응답 스펙에 맞추어 별도의 DTO를 반환한다.
	*/
	//조회 V1: 안 좋은 버전, 모든 엔티티가 노출, @JsonIgnore -> 이건 정말 최악, api가 이거 하나 인가! 화면에 종속적이지 마라!
     @GetMapping("/api/v1/members")
     public List<Member> membersV1() {
         return memberService.findMembers();
     }
}

문제점

• 엔티티에 프레젠테이션 계층을 위한 로직 추가됨
• 기본적으로 엔티티의 모든 값 노출됨
• 응답 스펙을 맞추기 위해 로직이 추가됨 (@JsonIgnore, 별도의 뷰 로직 등)
• 실무에서는 같은 엔티티에 대해 API 용도에 따라 다양하게 만들어지는데 한 엔티티에 각각의 API를 위한 프레젠테이션 응답 로직을 담기는 어려움
• 엔티티가 변경되면 API 스펙 변함
• 추가로 컬렉션을 직접 반환하면 향후 API 스펙을 변경하기 어려움 (별도의 Result 클래스 생성으로 해결)

결론 - API 응답 스펙에 맞추어 별도의 DTO 반환

참고) 엔티티 외부에 노출하지 마세요! 

        실무에서는 member 엔티티의 데이터가 필요한 API 계속 증가. 어떤 API는 name 필드가 필요하지만 어떤 API는 name 필드가 필          요없을 수 있음. 결론적으로 엔티티 대신에 API 스펙에 맞는 별도의 DTO를 노출해야함

 

 

 

V2 응답 값으로 엔티티가 아닌 별도의 DTO 사용

	/**
	* 조회 V2: 응답 값으로 엔티티가 아닌 별도의 DTO를 반환한다. */
     @GetMapping("/api/v2/members")
     public Result membersV2() {
	List<Member> findMembers = memberService.findMembers(); 
    
    //엔티티 -> DTO 변환
	List<MemberDto> collect = findMembers.stream()
                 .map(m -> new MemberDto(m.getName()))
                 .collect(Collectors.toList());
         
         return new Result(collect);
     }
     	@Data
 	@AllArgsConstructor
 	static class Result<T> {
     		private T data;
 	}
    
 	@Data
 	@AllArgsConstructor
 	static class MemberDto {
     		private String name;
 	}

• 엔티티를 DTO로 변환해 반환
• 엔티티가 변해도 API 스펙 변경되지 않음
• 추가로 Result 클래스로 컬렉션을 감싸서 향후 필요한 필드 추가 가능

 

 

 

참고 - 실전! 스프링 부트와 JPA 활용 2 (김영한)