[nestJS] 경로파라미터 일반경로 충돌 /seller/search /seller/:sellerID

  @ApiOperation({
    summary: "셀러 상세 조회",
    description: ""
  })
  @Get(":sellerId")
  async detail(@User() user, @Param() param: SellerIdParam) {
    const isExist = await this.sellersService.isExist(param.sellerId);
    if (!isExist) {
      throw new NotFoundException({
        status: HttpStatus.NOT_FOUND,

 

이것이 위에있고

  @ApiOperation({
    summary: "특정 셀러 조회",
    description: "핸드폰 번호 또는 닉네임을 기반으로 특정 셀러 정보를 조회합니다."
  })
  @Get("search")
  async findOne(
    @Query("information") information: string
  ) {
    console.log("wecametoinformation");
    console.log("information", information);

 

이것이 아래있었을때

 

sellerID를 안쳤다고 에러가 남. 왜그럴까?

 

/////////////////////////////////////////////////////////////////

 

NestJS에서 메소드의 순서가 영향을 미치는 이유는 특히 라우팅과 관련하여 발생할 수 있습니다. NestJS는 데코레이터를 사용하여 라우트를 등록하고, 이 라우트 등록은 컨트롤러 파일을 파싱하는 순서대로 이루어집니다. 따라서 메소드의 순서가 라우트 처리 순서에 영향을 줄 수 있습니다.

### 경로 파라미터와 일반 경로의 충돌
예를 들어, 다음과 같은 두 경로가 있을 때:

1. `@Get(":sellerId")` – 동적 경로 파라미터를 포함하는 경로
2. `@Get("search")` – 고정 경로

만약 `@Get(":sellerId")`가 `@Get("search")`보다 먼저 정의되어 있다면, `search`라는 문자열도 `:sellerId`의 파라미터로 해석될 수 있습니다. 이는 `search`가 동적 경로 파라미터 `:sellerId`에 해당할 수 있는 유효한 문자열로 인식되기 때문입니다. 따라서 `/sellers/search` 경로를 호출하면 `:sellerId`가 `search`로 설정된 `detail` 메소드가 호출될 수 있습니다.

### 문제 해결
메소드의 순서를 변경하여 고정 경로를 먼저 처리하도록 하면, NestJS는 먼저 고정 경로를 확인하고 일치하는 경로가 없을 때만 동적 경로를 확인합니다. 따라서, 다음과 같은 순서로 메소드를 정의하면:

1. `@Get("search")` – 고정 경로
2. `@Get(":sellerId")` – 동적 경로 파라미터

`/sellers/search` 요청이 들어올 때 `search`라는 문자열을 `sellerId` 파라미터로 해석하는 것이 아니라, `search` 경로를 처리하는 `findOne` 메소드를 정상적으로 호출하게 됩니다.

### 권장 사항
라우팅 관련 이슈를 방지하기 위해, 가능하면 다음과 같은 규칙을 따르는 것이 좋습니다:

- 고정 경로는 동적 경로보다 먼저 정의합니다.
- 동적 경로 파라미터를 포함하는 경로는 가장 마지막에 위치시키는 것이 안전합니다.
- 라우트의 구조와 순서를 명확히 문서화하여 유지보수 시 혼란을 방지합니다.

이러한 접근 방식은 경로 해석 과정에서의 예기치 않은 충돌과 버그를 방지하는 데 도움이 됩니다.