[Hoops PJ] 트러블 슈팅 & TIL (4)

May 8, 2024 5 분 소요

GET -> 동적 쿼리 어떻게 쓸까?

프론트 단에서 필터링 기능이 있었는데 이 부분을 어떻게 API로 구현할 지 고민을 했었다.
또한 상단에 있는 날짜에 따라서도 변해야 하며 경기 시작일이 조회 시점 시간보다 늦을 경우 해당 경기는 나오지 않도록 만들어야 했다.

처음에는 클릭할 때 마다 전부 다 Post로 처리하려고 했는데 좀 만들다보니 생각보다 너무 귀찮아서 GET으로 한 번에 처리하고 싶었다.

어떻게 하면 동적으로 변할 수 있는 모든 요구 사항에 만족하는 API를 하나로 만들 수 있을 까 고민하던 중 내가 알고 있는 지식에서 문제가 생겼다.

내가 아는 GET 방식은 파라미터가 꼭 들어가야 되는데 그렇다면 이 파라미터의 갯수가 달라졌을 경우 그에 따라 null 이 나오는 데이터들은 어떻게 처리하지?

따라서 다음과 같은 필요사항이 있었다.

파라미터의 갯수가 달라질 수 있다.
그에 맞게 결과 값이 정확하게 나와야 한다. (오류 나면 안됨)

우선 GET을 사용할 때 조건을 따로 어떻게 컨트롤할 수 있는지 다시 한 번 찾아봤고 보통 @RequestParam, @PathVariable 이렇게 두가지 어노테이션을 주로 사용하는 걸 알게 되었다.

@RequestParam vs @PathVariable 뭐가 다르지?

위 2개의 어노테이션은 GET 방식에서 주로 쓴다.
http의 비연결성을 극복하고 데이터를 전달하기 위한 방법들 중 하나로 uri를 통해 전달된 값을 파라미터로 받아오는 역할을 한다.

- http://localhost:8000/board?page=1&listSize=10  
- http://localhost:8000/board/1

여러개의 값을 받을 때는 @RequestParam 주로 하나의 값을 받을 때는 @PathVariable 여기서 @PathVariable 은 주로 uri에 전달 되는 값을 받아오는데 주로 post 요청에서 많이 쓴다.

보통 @RequestParam 를 통해서 Body 값에 json 형태로 요청하는데 해당 방식을 사용할 수 없을 때 @PathVariable 를 사용한다.

그럼 @RequestParam 을 사용하면 GET 요청으로도 충분히 동적으로 쿼리를 만들어 사용할 수 있다고 생각했다.

근데 또 다시 생각해보니까 의문점이 생겼다.

@GetMapping + @RequestParam 이랑 @PostMapping + @RequestBody 랑 별 차이가 없지 않나?

그래서 찾아보니 @PostMapping과 @RequestBody, @GetMapping과 @RequestParam이 이렇게 다르게 사용되는 이유는 HTTP 프로토콜의 설계 원칙과 RESTful 아키텍처의 제약 사항이 있다.

사실 뭘 해도 상관 없지만 해당 아키텍처를 따르는 게 좋다
(정말 꼭 필요한 경우가 아니라면 규격에 맞게 개발하는 게 좋다고 생각함)

HTTP GET 메서드의 제약 사항
- GET 요청은 서버의 리소스를 조회하기 위한 용도로 설계되었다.
- GET 요청에 본문(request body)을 포함하는 것은 HTTP 스펙을 위반하는 행위다.
- 따라서 GET 요청에서는 Query Parameter를 사용하여 필요한 데이터를 전달한다.
- 이러한 제약 사항 때문에 @GetMapping에서는 @RequestBody 대신 @RequestParam을 주로 사용한다.
HTTP POST 메서드의 목적
- POST 요청은 서버에 새로운 리소스를 생성하거나 기존 리소스를 업데이트하기 위해 사용된다.
- POST 요청은 본문(request body)에 데이터를 포함할 수 있다.
- 이러한 목적에 따라 @PostMapping에서는 @RequestBody를 사용하여 클라이언트로부터 전송된 데이터를 자바 객체로 deserialize 한다.
RESTful 아키텍처 스타일
- RESTful 아키텍처에서는 HTTP 메서드를 의미에 맞게 사용하는 것이 중요합니다.
- GET은 리소스 조회, POST는 리소스 생성, PUT은 리소스 업데이트, DELETE는 리소스 삭제 등의 용도로 사용된다.
- 이러한 규약을 따르면서 데이터를 효율적으로 전송하기 위해 @RequestBody와 @RequestParam을 적절히 구분하여 사용한다.

그럼 동적으로 여러 조건에 따라 결과 값도 달라지게 만들려면 어떻게 해야될까?

QueryDSL을 사용하는 방식과 Specification을 사용해서 만드는 방법 두 가지를 찾았다.

첫 번째의 경우 SQL문을 객체처럼 만들어서 사용할 수 있는데 라이브러리에 의존하게 된다. 설치하고 찾아보는 게 귀찮기도 했고 그다지 복잡한 요구사항이 아니라서 그냥 Specification 을 사용해서 구현했다.

또한 현재 프로젝트의 서비스 특성상 복잡한 쿼리로 확장하게 될 것 같지 않아서 Specification을 선택한 이유도 있다.

컨트롤러

public class GameUserController {  
  
  private final GameUserService gameUserService;  
  
  @GetMapping("/search")  
  public ResponseEntity<List<GameSearchResponse>> findFilteredGames(  
      @RequestParam(required = false) LocalDate localDate,  
      @RequestParam(required = false) CityName cityName,  
      @RequestParam(required = false) FieldStatus fieldStatus,  
      @RequestParam(required = false) Gender gender,  
      @RequestParam(required = false) MatchFormat matchFormat) {  
    return ResponseEntity.ok(  
        gameUserService.findFilteredGames(localDate,  
            cityName, fieldStatus, gender, matchFormat));  
  }

이런 식으로 기본 값을 false로 두고 해당 파라미터의 값이 들어오면 (True) Specification 를 사용해서 객체로서 쿼리를 조정해준다.

서비스 (리팩토링 전)

public List<GameSearchResponse> findFilteredGames(  
    LocalDate localDate,  
    CityName cityName,  
    FieldStatus fieldStatus,  
    Gender gender,  
    MatchFormat matchFormat) {  
  
  Specification<GameEntity> spec = getGameEntitySpecification(  
      localDate, cityName, fieldStatus, gender, matchFormat);  
  
  List<GameEntity> gameListNow = gameUserRepository.findAll(spec);  
  
  Long userId = null;  
  
  return getGameSearchResponses(gameListNow, userId);  
}
private static Specification<GameEntity> getGameEntitySpecification(  
    LocalDate localDate, CityName cityName, FieldStatus fieldStatus,  
    Gender gender, MatchFormat matchFormat) {  
  Specification<GameEntity> spec = Specification.where(  
      GameSpecifications.startDate(LocalDate.now())  
          .and(GameSpecifications.notDeleted()));  
  
  if (localDate != null) {  
    spec = Specification.where(  
        GameSpecifications.withDate(localDate)  
            .and(GameSpecifications.notDeleted()));  
  }  
  if (cityName != null) {  
    spec = spec.and(GameSpecifications.withCityName(cityName));  
  }  
  if (fieldStatus != null) {  
    spec = spec.and(GameSpecifications.withFieldStatus(fieldStatus));  
  }  
  if (gender != null) {  
    spec = spec.and(GameSpecifications.withGender(gender));  
  }  
  if (matchFormat != null) {  
    spec = spec.and(GameSpecifications.withMatchFormat(matchFormat));  
  }  
  return spec;  
}

GameSpecifications 클래스

public class GameSpecifications {  
  
  public static Specification<GameEntity> withCityName(CityName cityName) {  
    return (root, query, criteriaBuilder) ->  
        criteriaBuilder.equal(root.get("cityName"), cityName);  
  }  
  
  public static Specification<GameEntity> withFieldStatus(  
      FieldStatus fieldStatus) {  
    return (root, query, criteriaBuilder) ->  
        criteriaBuilder.equal(root.get("fieldStatus"), fieldStatus);  
  }  
  
  public static Specification<GameEntity> withGender(Gender gender) {  
    return (root, query, criteriaBuilder) ->  
        criteriaBuilder.equal(root.get("gender"), gender);  
  }  
  
  public static Specification<GameEntity> withMatchFormat(  
      MatchFormat matchFormat) {  
    return (root, query, criteriaBuilder) ->  
        criteriaBuilder.equal(root.get("matchFormat"), matchFormat);  
  }  
  
  public static Specification<GameEntity> startDate(  
      LocalDate date) {  
    return (root, query, criteriaBuilder) ->  
        criteriaBuilder.equal(  
            root.get("startDateTime").as(LocalDate.class), date);  
  }  
  
  public static Specification<GameEntity> notDeleted() {  
    return (root, query, criteriaBuilder) ->  
        criteriaBuilder.isNull(root.get("deletedDateTime"));  
  }  
  
  public static Specification<GameEntity> withDate(LocalDate date) {  
    return (root, query, criteriaBuilder) ->  
        criteriaBuilder.equal(  
            root.get("startDateTime").as(LocalDate.class), date);  
  }  
}

서비스 (리팩토링 후 + 페이징 처리)

public Page<GameSearchResponse> findFilteredGames(  
    LocalDate localDate, CityName cityName, FieldStatus fieldStatus,  
    Gender gender, MatchFormat matchFormat, int page, int size) { 
      localDate,  
      cityName,  
      fieldStatus,  
      gender,  
      matchFormat  
  );  
  Specification<GameEntity> spec = getGameEntitySpecification(  
      localDate, cityName, fieldStatus, gender, matchFormat);  
  
  List<GameEntity> gameListNow = gameUserRepository.findAll(spec);  
  
  Long userId = null;  
  
  log.info("findFilteredGames 종료");  
  return getPageGameSearchResponses(gameListNow, userId, page, size);  
}

여기서 userId를 null로 둔 이유는 getPageGameSearchResponses를 myLastGameList , myCurrentGameList 도 함께 사용하는데 해당 API는 회원가입을 하지 않고도 조회할 수 있도록 만들기 위해서 null 값으로 초기화 해서 사용했다.

private static Page<GameSearchResponse> getPageGameSearchResponses(  
    List<GameEntity> gameListNow, Long userId, int page, int size) {  
  List<GameSearchResponse> gameList = new ArrayList<>();  
  gameListNow.forEach(  
      (e) -> gameList.add(GameSearchResponse.of(e, userId)));  
  
  log.info("game list : " + gameList);  
  log.info("gameListNow : " + gameListNow);  
  int totalSize = gameList.size();  
  int totalPages = (int) Math.ceil((double) totalSize / size);  
  int lastPage = totalPages == 0 ? 1 : totalPages;  
  
  page = Math.max(1, Math.min(page, lastPage));  
  
  int start = (page - 1) * size;  
  int end = Math.min(page * size, totalSize);  
  
  List<GameSearchResponse> pageContent = gameList.subList(start, end);  
  PageRequest pageable = PageRequest.of(page - 1, size);  
  return new PageImpl<>(pageContent, pageable, totalSize);  
}

위의 코드를 보면 userId가 null 값으로 처리했기 때문에 쿼리 값에 맞는 모든 게임 데이터를 불러올 수 있다.

또한 분리한 getGameEntitySpecification 는 아래와 같이 분리해 두었다.

private static Specification<GameEntity> getGameEntitySpecification(  
    LocalDate localDate, CityName cityName, FieldStatus fieldStatus,  
    Gender gender, MatchFormat matchFormat) {  
  Specification<GameEntity> spec = Specification.where(  
      GameCheckOutSpecifications.notDeleted());  
  
  spec = spec.and(GameCheckOutSpecifications.startDate(localDate));  
  
  if (cityName != null) {  
    spec = spec.and(GameCheckOutSpecifications.withCityName(cityName));  
  }  
  if (fieldStatus != null) {  
    spec = spec.and(  
        GameCheckOutSpecifications.withFieldStatus(fieldStatus));  
  }  
  if (gender != null) {  
    spec = spec.and(GameCheckOutSpecifications.withGender(gender));  
  }  
  if (matchFormat != null) {  
    spec = spec.and(  
        GameCheckOutSpecifications.withMatchFormat(matchFormat));  
  }  
  return spec;  
}

Specification를 사용하면 직접 쿼리를 작성하는 것 보다 조건을 동적으로 구성할 수 있고 실행 로직 분리로 인해 코드 가독성에 대한 이점이 있다.

QueryDSL도 비슷하지만 조건을 추가하거나 삭제 또는 수정할 때 재사용성이 나쁘지 않다고 생각했고 중복 코드를 줄일 수 있으며 객체 지향 프로그래밍 스타일에 부합하다고 생각했다.

하지만 단점도 있는데 지금 조건이 그렇게 많지 않은데도 복잡해 보인다.
여기서 더 조건이 많아지면 그만큼 복잡해질 수도 있고 불필요한 조인이나 서브쿼리등 성능 이슈가 발생할 수 있다.

또한 복잡한 쿼리를 작성하기 어려울 수 있다.

성능 면에서는 직접쿼리가 좋다고 생각하지만 재사용성이나 가독성이 좋지 않다고 생각한다.

추가로 SQL인젝션 공격 등의 보안 위험도 생각해 볼 수 있다.

좀 더 공 부? https://tecoble.techcourse.co.kr/post/2022-10-11-jpa-dynamic-query/

Twitter Facebook LinkedIn

[Hoops PJ] 트러블 슈팅 & TIL (4)

GET -> 동적 쿼리 어떻게 쓸까?

@RequestParam vs @PathVariable 뭐가 다르지?

@GetMapping + @RequestParam 이랑 @PostMapping + @RequestBody 랑 별 차이가 없지 않나?

그럼 동적으로 여러 조건에 따라 결과 값도 달라지게 만들려면 어떻게 해야될까?

컨트롤러

서비스 (리팩토링 전)

GameSpecifications 클래스

서비스 (리팩토링 후 + 페이징 처리)

공유하기

댓글남기기

참고

[Todo] 트러블 슈팅 & TIL (1)

[Hoops PJ] 트러블 슈팅 & TIL (8)

[Hoops PJ] 트러블 슈팅 & TIL (7)

[Hoops PJ] 트러블 슈팅 & TIL (6)