JPA 활용 2 - 회원 등록 API

회원 등록 API

• 이전 코드 : https://github.com/rhqudco/SpringLearn/tree/master/jpashop

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

@RestController
@RequiredArgsConstructor
public class MemberApiController {

    private final MemberService memberService;

    @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에 매핑

@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);
}

@Data
static class CreateMemberRequest { // DTO 역할
    private String name;
}

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

엔티티를 매핑해서 그대로 사용하면 개발자 입장에서는 문서를 확인하지 않으면 어떤 파라미터를 넣어줘야 하는지 알 수 없다.
하지만 DTO를 보면 어떤 파라미터를 넣어줘야 하는지 쉽게 알 수 있다.
또, 같은 엔티티를 사용하는 다른 API일지라도 검증해야 하는 값이 모두 다를 수 있는데 검증 로직을 엔티티와 분리할 수 있기 때문에 API 스펙에 딱 맞게 개발할 수 있는 장점과 유지보수가 편리하다는 장점이 있다.

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

인프런 김영한 지식공유자님 강의 - 실전! 스프링 부트와 JPA 활용2 - API 개발과 성능 최적화