[워밍업 클럽 BE-0기] 7일차 과제 - JPA로의 전환, 그리고 더 다양한 API 만들
7일차 과제는 기존의 프로젝트를 JPA로 전환하고, 더 다양한 API를 만드는 것입니다.
저는 이미 과제를 처음부터 JPA로 진행하고 있었으므로, 해당 부분을 생략하고 문제를 바로 보겠습니다.
첫 번째 문제는 다음의 스펙에 맞추어 API를 만드는 것입니다.
HTTP method : GET
HTTP path : /api/v1/fruit/count
HTTP query : name -> 과일 이름
HTTP 응답 Body 예시
{
"count" : long
}
코드는 다음과 같습니다!
FruitController
FruitService
FruitRepository
이름을 파라미터로 넘겨주면 그 이름과 일치하는 과일 엔티티들의 갯수를 반환하도록 했고요. 아래와 같이 요청을 보냈습니다.
그리고 현재 제가 만든 Fruit 테이블의 상태는 아래와 같습니다. 사과가 3개 있으니 3개를 가져와야할 것입니다.
정상적으로 3개가 출력되는 것을 확인할 수 있었습니다.
다음 문제는 팔리지 않은 과일들 중에서 특정 금액 이상, 혹은 특정 금액 이하의 과일 목록을 받아오는 것입니다.
스펙은 아래와 같습니다
HTTP method : GET
HTTP path : /api/v1/fruit/list
HTTP query
option : "GTE" 혹은 "LTE"라는 문자열이 들어온다.
GTE는 크거나 같다는 의미
LTE는 작거나 같다는 의미
price : 기준이 되는 금액이 들어온다.
응답 Body 예시
[{
"name" : String,
"price" : long,
"warehousingDate" : LocalDate,
}, ... ]
저는 아래와 같이 코드를 작성했습니다.
FruitController
FruitService
FruitRepository
그리고 요청을 보내보았습니다.
정상 작동을 확인했습니다.
다만 아쉬운 점이 서비스레이어에서 엔티티를 DTO로 변환을 하는 과정인데.. 이것을 그냥 레포지토리에서 DTO로 조회를 하는 방식이 더 나을 것 같다는 생각이 들었습니다. 하지만 이렇게 되면 쿼리 애노테이션을 달아주어 SQL을 작성해줘야하는데 레포지토리에 있는 코드들이 길어질 것 같았습니다. 어떤 방식이 더 선호되는 지는 공부를 해보고 개선해봐야겠습니다. 저 변환을 하는 작업이, 필드가 늘면 늘수록 중간 연산의 코드가 점점 더 길어지게 되는 단점이 있다고 생각이 들었거든요.
그럼 오늘도 봐주셔서 감사드리고 모든 워밍업 클러버들의 무운을 빕니다.
댓글을 작성해보세요.