서론
오늘 JPA의 기초적인 지식들 가지고 간단한 웹을 하나 만들었지만 문제가 생겼다. 바로 API다. 결국 JPA던 뭐던 API를 할 줄 알아야 협업을 통한 개발이 수월하다는 것을 깨달았다. 이제부터 JPA에서의 API 활용을 알아봅시다.
엔티티를 API에 직접적으로 노출
@PostMapping("/api/v1/members")
public CreateMemberResponse saveMemberV1(@RequestBody @Valid Member member){
Long id = memberService.join(member);
return new CreateMemberResponse(id);
}요청 값으로 Member 엔티티를 직접 받을 때의 문제점
- 엔티티에 프레젠테이션 계층을 위한 로직이 추가된다.
- API 검증을 위한 로직이 들어가야한다.
- 한 엔티티에 각각의 API를 위한 모든 요청 요구사항을 담기는 어렵다.
- 엔티티가 변경되면 API 스펙이 변한다.
결론
- 엔티티를 API에 직접적으로 넘기기 말자
- API 요청에 따라 DTO(데이터 전송 객체)를 파라미터로 받자
Request 값을 엔티티 대신 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);
}요청 값으로 Member 엔티티 대신에 별도의 DTO를 받을때의 장점
- 엔티티와 프레젠테이션 계층을 위한 로직을 분리할 수 있다.
- 엔티티와 API 스펙을 명확하게 분리할 수 있다.
- 엔티티가 변해도 API 스펙이 변하지 않는다.
마치며 ..
오늘은 등록 API만 구현해봤다. 하지만 등록 API 뿐만 아니라 수정, 삭제, 조회 또한 엔티티 대신 DTO를 매핑하여 구현해야한다. 특히 조회는 굉장히 많은 데이터와 관련이 있기 때문에 성능도 최적화를 시켜주어야 한다. 앞으로 조회의 성능 최적화에 대해서 알아보자
