JPA - API 개발과 성능 최적화

API 개발 기본 - 회원 등록, 수정, 조회 API

회원 등록 API

등록 v1 엔티티를 Request Body에 직접 매핑

MemberApiController.kt

@PostMapping("/api/v1/members")
fun saveMemberV1(@RequestBody member: @Valid Member): CreateMemberResponse {
    val id: Long = memberService.join(member)
    return CreateMemberResponse(id)
}

data class Result<T>(
    val data: T
)

data class CreateMemberRequest(
    val name: String
)

data class CreateMemberResponse(
    val id: Long
)

요청 값으로 Member 엔티티를 직접 받는다.

문제점

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

등록 v2 엔티티 대신에 DTO를 RequestBody에 매핑

MemberApiController.kt

@PostMapping("/api/v2/members")
  fun saveMemberV2(@RequestBody request: @Valid CreateMemberRequest): CreateMemberResponse {
      val member = Member(
          name = request.name
      )

      val id: Long = memberService.join(member)
      return CreateMemberResponse(id)
  }

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

해결방법

등록 v2와 같이 API 요청 스펙에 맞추어 별도의 DTO를 파라미터로 받는다.
실무에서는 절대로 엔티티를 API 스펙에 노출하면 안된다.

회원 수정 API

MemberApiController.kt

@PutMapping("/api/v2/members/{id}")
fun updateMemberV2(
    @PathVariable("id") id: Long,
    @RequestBody request: @Valid UpdateMemberRequest
): UpdateMemberResponse {
    memberService.update(id, request.name)
    val findMember = memberService.findOne(id)
    return UpdateMemberResponse(findMember.id!!, findMember.name)
}

data class UpdateMemberRequest(
    val name: String
)

data class UpdateMemberResponse(
    val id: Long,
    val name: String,
)

변경 감지를 사용해서 데이터 수정

MemberService.kt

@Service
class MemberService(
    @Autowired private val memberRepository: MemberRepository,
) {
    @Transactional
    fun update(id: Long, name: String) {
        val member = memberRepository.findOne(id)
        member.name = name
    }
}

회원 조회 API

조회 v1 응답 값으로 엔티티를 직접 외부에 노출

MemberApiController.kt

@GetMapping("/api/v1/members")
fun membersV1(): List<Member> {
    return memberService.findMembers()
}

문제점

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

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

MemberApiController.kt

@GetMapping("/api/v2/members")
fun membersV2(): Result<List<MemberDto>> {
    val findMembers = memberService.findMembers()
    //엔티티 -> DTO 변환
    val collect = findMembers.map { MemberDto(it.name) }
    return Result(collect)
}

data class Result<T>(
    val data: T
)

data class MemberDto(
    val name: String
)

엔티티를 DTO로 변환해서 반환한다.
엔티티가 변해도 API 스펙이 변경되지 않는다.
추가로 Result 클래스로 컬렉션을 감싸서 향후 필요한 필드를 추가할 수 있다.

소스코드

참조

https://www.inflearn.com/course/스프링부트-JPA-API개발-성능최적화/dashboard