@RequestBody @RequestPart @RequestParam @PathVariable

 

 

오늘은 SpringBoot Controller 단에서 가장 많은 형태로 받아오는 

@RequestBody

@RequestPart

@RequestParam

@PathVariable

어노테이션 4가지에 대해 각각 특징을 알아보겠습니다.

 

@RequestBody

@RequestBody는 JSON 형태의 데이터를 Java 객체에 매핑할 때 사용하는 어노테이션입니다.

 

Object의 변환을 위해 @RequestBody 어노테이션을 선언해주면 Spring의 HTTP 요청으로 넘어오는 body의 내용을 HttpMessageConverter를 통해 Java Object로 역직렬화합니다. multipart 요청이 아닌, 즉 어떤 바이너리 파일을 포함하고 있지 않은 데이터를 받는 역할을 해줍니다.

@Getter
@Setter
@NoArgsConstructor
@AllArgsConstructor
@ToString
public class testDto {
    private String userName;
    private Integer age;
}
 
 @PostMapping("/api/v1/test")
 public ResponseEntity<?> test(
    @RequestBody testDto test //RequestBody 사용
)

 

위와 같이 사용하게 된다면 아래와 같은 데이터를 프론트에서 백엔드로 보낼 수 있습니다.

POST http://localhost:8080/api/v1/test
Content-Type: application/json

{
    "userName": "testUser",
    "age": 20
}

 

제가 인턴을 하고 있는 회사는 전자정부 프레임워크를 사용하고 있었기 때문에 Srping 버전이 4.0 이었습니다.

Srping에서는 4.2.x 부터 Delete 메서드에 대해서 Strping의 내장된 RestTemplete 객체가 body를 셋팅해주지만, 저희는 4.0 버전을 사용하고 있었기 때문에 DeleteMapping에 대해서 Requestbody를 사용하지 못하였습니다.

 

=> 해당 오류를 해결하기 위해서 DeleteMpping 대신 PutMapping으로 대체하였습니다.

 

@RequestPart

파일과 함께 form-data를 보내는 식으로 Content-type이 'multipart/form-data' 일 때 사용합니다.

 

MultipartFile이 포함되는 경우에 HttpServeltRequest에서 MultipartHttpServletRequest로 변환하게 됩니다. 디스패처 서블릿에는 DefaultStratage로 등록되는 Bean이 따로 존재하지 않고, SpringBoot에서 StandardServletMultipartResolver가 기본으로 등록되게 됩니다.

만약 MultipartFile이 포함되지 않는 경우에는 @RequestBody와 같이 HttpMessageConverter가 동작하게 됩니다. @RequestBody가 필요하지만 (MultipartFile 같은)Binary Stream이 포함되는 경우에 사용할 수 있습니다.

@GetMapping(value = "/file", consumes = {MediaType.APPLICATION_JSON_VALUE, MediaType.MULTIPART_FORM_DATA_VALUE})
public ResponseEntity<?> savePostFile(
  @RequestPart("data") PostRequestDTO postRequestDTO,
  @RequestPart(value = "file", required = false) MultipartFile multipartFile) throws IOException {

 

위와 같은 형태로 MultipartFile과 함께 Form-data를 파라미터로 받을 수 있습니다.

유의점으로는 API에서 consumes를 지정하여 MediaType을 명시해주어야합니다.

RequestPart에서 required, value를 설정해줄 수 있습니다.

 

@RequestParam

하나의 파라미터만 받을 수 있습니다. 

value, required를 사용할 수 있고 default 값을 지정해줄 수 있습니다.

HTTP 파라미터 이름이 변수 이름과 같으면 @RequestParam의 value를 생략할 수 있습니다.

기본적으로 파라미터가 들어도록 설정되어 있기 때문에 필수 값이 아니라면 required를 false로 지정하여 BadRequest를 막을 수 있습니다. 

 

@GetMapping("/users")
public ResponseEntity<?> searchUsers(
    @RequestParam(required = false) String name,
    @RequestParam(required = false) Integer age,
    @RequestParam(required = false) String city) {
}

 

위 코드와 같이 필터링처리(Query String)를 할 때 리소스를 정확하게 식별해야하는 @PathVariable 대신  RESTFul API 설계 원칙을 준수하기 위해 ReqeustParam을 유용하게 사용할 수 있습니다. 

 

@PathVariable

앞서 얘기한 것처럼 리소스를 정확하게 식별하는 URL 경로 변수를 필요로 할때 사용합니다.

default 값을 지정할 수 없고, 필수로 URL에 변수가 존재해야합니다. 

    @GetMapping("/{id}")
    public ResponseEntity<?> getUserById(@PathVariable Long id) {
  }

 

위와 같은 형태로 url에 해당 파라미터가 존재하지 않으면 404 BadRequest가 발생합니다.