이번 포스팅에서는 쿼리 스트링과 요청 DTO의 차이점에 대해 기록한다.
오늘 과제에서 생긴 문제를 해결하던 중에 팀원분들에게 조언을 받았다.
나는 회원 이름으로 조회할 때 @RequestParam을 이용해서 쿼리 스트링으로 조회했는데, 팀원분들은 GetMemberRequest 처럼 DTO로 이름을 받아서 구현하셨다고 했다.
@GetMapping("/api/members")
public ResponseEntity<GetMemberResponse> getMemberByName(@RequestParam("name") String name) {
return ResponseEntity.status(HttpStatus.OK).body(memberService.findMemberByName(name));
}두 방식에 무슨 차이가 있는지 궁금해서 알아보았다.
🌱 @RequestParam
데이터 위치
- URL의 쿼리 스트링 부분
/api/members/?name=홍길동"
데이터 전달
- 개별 파라미터로 전달된다.
Spring에서의 처리
@RequestParam 어노테이션을 사용해서 요청 파라미터의 이름("name")과 컨트롤러 메소드의 파라미터(String name)을 직접 매핑한다.
특징
- 파라미터가 적을 때는 코드가 직관적이고 간결하다.
- GET 요청은 원래 URI/쿼리 스트링을 통해 리소스 식별 또는 필터링 정보를 전달하는 것이 일반적이다.
🌱 요청 DTO 방식(GetMemberRequest)
데이터 위치
- GET 요청의 경우
@ModelAttribute를 사용하여 쿼리 스트링의 여러 파라미터를 DTO의 필드에 바인딩한다. - 주로 이 방식을 사용한다.
- POST나 PUT 요청의 경우 요청 본문(Body)에 JSON/XML 형태로 전달하고, 이 경우
@RequestBody를 사용한다.
데이터 전달
- 관련된 여러 파라미터를 하나의 객체(DTO)로 묶어 전달한다.
Spring에서의 처리
- Spring이 요청 파라미터들을 DTO 객체의 필드에 자동으로 바인딩한다.
특징
- 조회 조건(파라미터)이 늘어날 경우 DTO에 필드만 추가하면 되므로 확장성과 응집도가 높다.
- DTO에 검증(Validation) 로직을 함께 정의하여 여러 곳에서 재사용하기에 용이하다.
🌱 실무에서의 사용
✅ 단일 조건 조회: @RequestParam 권장
- 단일 조건으로 조회할 경우에는
@RequestParam을 사용하는 것이 코드를 간결하게 하고 직관적이다. - 확장성을 고려할 경우에는 단일 조건 조회 시에도 요청 DTO를 써도 좋을 것 같다.
✅ 복합 조건 조회: 요청 DTO 권장
- 파라미터가 2~3개 이상일 경우, DTO를 사용하면 파라미터 목록이 길어지는 것을 방지하고 코드의 응집성과 유지보수성이 높아진다.
✅ 검증 필요: 요청 DTO 권장
@Valid나@Validated를 활용하여 DTO에서 일괄적으로 입력값 검증을 수행하기 편리하다.
🌱 마치며
일반적으로 조회 조건(파라미터)가 2개가 넘어가거나, 앞으로 늘어날 가능성이 있다고 판단되면 요청 DTO를 사용하는 게 좋아보인다.
조회 필터링 조건이 늘어나도 메소드 시그니처를 변경하지 않아도 되기 때문이다.
