@RequestParam, @RequestBody, @PathVariable 방식

스프링 부트로 프로젝트를 개발하게되면 Controller에서 프론트로부터 파라미터를 전달받아야 하는 순간이 온다.

파라미터를 전달받는 방식에는 여러가지가 있지만 이번 포스팅에선 @RequestParam, @PathVariable, @RequestBody 3가지에 대해서 다뤄보자.

 

1. @RequestParam 

GET 방식으로 넘어온 URI(Uniform Resource Identifier : 통합 자원 식별자) 에서 queryString 형태의 정보를 추출해내는 방식이다.

예를 들면, api 요청시에 URI가 http://localhost:8080/schedule?id=1 이면 queryString 형태의 정보는 ?id=1 이다.

@GetMapping("/schedule")
public ScheduleResponseDto getSchedule(@RequestParam Long id){
	return scheduleService.getSchedule(id);
}

 위의 코드블럭은 기본적으로 MVC 패턴에서 controller 부분을 (controller + service + repository) 3개로 나눈 상태를 가정한 코드이다. getSchedule메소드의 파라미터인 (@RequestParam Long id) 에 queryString 에서의 id=1  값이 들어가게 된다.

 

2. @RequestBody

@RequestBody 형식은 클라이언트에게서 전달된 body 의 내용을 객체로 매핑해준다. 예를 들면,

----------------------
@Setter
@AllArgsConstructor
class RequestDto {
	private String title;
    private String contents;
}

----------------------

@PostMapping("/schedule")
public Long createSchedule(@RequestBody RequestDto requestDto){
	return scheduleService.create(requestDto);
}

 위의 코드에서 POST 메소드와 함께 전달된 body의 내용이 아래의 JSON 형식이라면,

{
	"title" : "PT lesson",
    "contents" : "Gym PT orientation at 9pm"
}

 

requestDto 의 field인 title = "PT lesson" 으로 contents = "Gym ~~ at 9pm" 으로 매핑된다.

 

3. @PathVariable

이 방식은 api를 매핑할 때 차이점이 있다. 위의 @RequestParam의 예제를 변형시켜보자.

@GetMapping("/schedule/id/{id}")
public ScheduleResponseDto getSchedule(@RequestParam Long id){
	return scheduleService.getSchedule(id);
}

api 요청시에 URI가 http://localhost:8080/schedule/id/1 의 형태로 요청이 전달된다.

 

내 생각

파라미터로 받아야할 필드가 많다면 @RequestBody형식으로 객체로 매핑하는게 편할 것 같다.

그게 아니라 받아야할 파라미터가 2개 이하라면, 즉 간단한 id 값 정도를 받는 작업은 @RequestParam 이나 @PathVariable을 사용할 것 같다.