@PathVariable vs @RequestParam

@PathVariable

• 설명: @PathVariable은 URL 경로의 일부로 전달되는 값을 매핑할 때 사용합니다. RESTful 스타일의 API 설계에서 자주 사용되며, 리소스의 특정 부분을 식별하는 데 유용합니다.

예시 :

 

@GetMapping("/users/{userId}")
public String getUser(@PathVariable("userId") Long userId) {
    // userId를 사용하여 사용자 데이터를 처리
    return "User ID: " + userId;
}

 

 

이 경우, /users/123라는 요청을 받으면 userId에 123이 매핑됩니다.

 

• 장점:
  1. RESTful 설계에 적합: URL 경로 자체에 리소스의 식별자를 포함할 수 있어 명확한 API 설계를 할 수 있습니다. 예를 들어, /users/123에서 123은 특정 사용자를 나타내므로 직관적입니다.
  2. 데이터 캡슐화: URL 경로에서 리소스를 특정지을 수 있으므로, 명시적으로 데이터를 전달하는 구조입니다.
• 단점:
  1. 유연성 제한: URL 패턴이 고정적입니다. 다수의 파라미터를 전달할 때 URL 경로가 복잡해질 수 있습니다.
  2. 데이터 전달 한정: 경로 변수로 전송할 수 있는 데이터는 단순 값(숫자나 문자 등)으로 제한됩니다.

 

 

 

@RequestParam

• 설명: @RequestParam은 URL의 쿼리 파라미터를 받아올 때 사용됩니다. 주로 필터링, 검색, 페이징과 같은 다양한 옵션을 전달할 때 사용됩니다.

예시 :

@GetMapping("/users")
public String getUsers(@RequestParam("page") int page, @RequestParam("size") int size) {
    // 페이지와 사이즈 정보를 이용한 처리
    return "Page: " + page + ", Size: " + size;
}

 

 

 

이 경우, /users?page=1&size=20라는 요청을 받으면 page는 1, size는 20으로 매핑됩니다.

 

• 장점:
  1. 유연성: URL 경로가 고정되지 않고, 여러 파라미터를 쉽게 전달할 수 있습니다. 다수의 필드를 넘길 때 유용합니다.
  2. 가독성: 여러 조건을 전달할 때 URL이 덜 복잡하게 유지됩니다. /users?page=1&size=20은 리소스를 나타내지 않고 추가적인 조건을 명시합니다.
• 단점:
  1. URL이 길어질 수 있음: 다수의 파라미터를 전달할 때, URL 쿼리 스트링이 길어지고 복잡해질 수 있습니다.
  2. 리소스 식별에 부적합: 리소스를 명확하게 식별하지 않고, 대신 리소스에 대한 속성을 전달하는 형태이기 때문에, 식별자보다는 조건을 표현하는 데 적합합니다.