사용자에게 보여지는 페이지의 URL을 구성하면서, 또 서버 API 요청 URL을 구성하면서 path param과 query param 에 대한 정확한 개념이 잡혀 있지 않아서 찾아 보게 되었다. 글이 REST API에 이용되는 경우에 한정되지는 않았지만 어쨌든 기반되는 내용이니 해당 시리즈로 묶었다. 👀

Query Parameters

(URL Parameters / Query Strings)
콘텐츠를 필터링하고 구성하는 데 도움을 주기 위해 URL에 삽입되는 요소

/users?id=123&sort=newest

• 키-값 쌍으로 매개변수 제공
• 정렬, 필터링, 검색을 원하는 경우 사용
  

작동 방식

1. 콘텐츠 수정

페이지에 표시되는 콘텐츠를 수정

• 예를 들면, https://domain.com/t-shirts?color=black는 검정색 티셔츠를 보여주기 위해 페이지를 업데이트

2. 추적

사용자가 어느 네트워크에서 유입되었는지, 사용자가 클릭한 광고 등 정보를 기록

• 페이지에 표시되는 콘텐츠를 수정하지 않음
• 예를 들면, https://www.domain.com/?utm_source=newsletter&utm_medium=email는 이메일 뉴스레터의 트래픽을 추적

SEO와 Query Parameters

가능한 문제 상황

1. 중복 콘텐츠

검색 엔진은 모든 URL을 별도 취급하므로, URL parameter로 생성된 동일한 페이지의 여러 버전은 중복 콘텐츠로 간주될 수 있음

2. 크롤링 예산 낭비

여러 매개변수가 복잡하게 얽혀있는 URL이 동일하거나 유사한 콘텐츠를 가리키므로, 크롤러가 대역폭을 낭비하거나 콘텐츠 색인화에 어려움을 겪을 수 있음

3. 키워드 카니발라이제이션 (자기잠식)

동일한 키워드를 놓고 여러 페이지가 경쟁하므로, 검색 엔진이 어떤 페이지로 랭킹을 매겨야 할지 혼동할 수 있음

4. 랭킹 시그널 약화

동일한 콘텐츠를 포함한 URL이 여러개면, 사용자들은 parameter가 이용된 페이지로 갈 수도 있으므로 메인 페이지의 전체 랭킹이 낮아질 수 있음

5. URL 가독성 저하

검색 엔진 결과 페이지(SERP, Search Engine Result Page)에 표시될 때 신뢰할 수 없어 보이므로 사용자가 클릭할 가능성이 낮아짐

해결

1. 일관된 내부 연결

2. 한 버전의 URL 표준화

3. Disallow로 크롤러 차단 (robots.txt)

Request Parameter

클라이언트의 요청을 통해 서버에 전달하는 URL parameter

• GET 요청에 사용

Path Variable

매개변수 직접 포함, 경로를 변수로 사용 (엔드 포인트의 일부)

/users/123

어떤 resource를 식별하고 싶은 경우 사용 (전체 정보를 불러오고 싶을 때)

Request Body

• 주로 post, put에 사용 (데이터를 생성하거나 수정할 때)

참고

https://ryan-han.com/post/translated/pathvariable_queryparam/
https://hyriverstudy.tistory.com/33
https://www.semrush.com/blog/url-parameters/
https://devraphy.tistory.com/509