36~40일차 스터디

Path Variable과 Query Parameter(Query String)??

Path Variable? Query Parameter? query strings? path parameter? URL parameter?

 

서버 만들기 과제를 하느라 라우터를 만드는 과정에서 주소 나누는 게 헷갈려서 검색을 했는데, 정작 이 파라미터에 관한 용어가 너무 많고 혼용 되어서 당황한 김에 다뤄보기로 했습니다. parameter는 매개변수입니다. 즉, 이 경우에는 url 경로에 도입되는 매개변수를 말하는데요. 웹에서 특정 데이터를 전송하고 받기 위해서 어디(End-point)에 요청할 것인가는 중요한 문제라고 할 수 있죠. 우리는 매개변수를 사용해 동적 부분을 변수로 처리하여 동적 라우팅 기능을 구현합니다.

 

잠깐. 라우팅이란? 다른 경로에 따라서 다른 화면을 보여주는 것

 

이런 매개변수는 페이지 주소를 정의할 때 유동적인 값을 전달해야 하는 경우 사용합니다.

Path Variable과 Query Parameter은 둘다 URL에서 정보를 전달하는 방법입니다.

 

🚩Path Variable

Path Variable 는 URL의 경로에 값을 포함시켜 전달해줍니다.

Path Variable = Path Parmeter

 

Path 라는 이름에서도 알 수 있듯이 경로를 변수로서 사용합니다. 경로를 지정하여 요청을 보내기 때문에, 구체적인 리소스를 식별할 경우 사용됩니다.

 

언제 사용?→ 위치를 특정해서 보여주는 경우. 리소스를 식별하는 경우. 원하는 정보가 한 가지일 때.

/users/123    # 아이디가 123인 사용자를 가져온다.
/post/6   # post에서 6번째 글을 조회한다.

위와 같은 URL에서 123는 users의 매개변수로 전달됩니다. 일반적으로 특정 id나 이름을 조회할 때 사용합니다. 서버에 요청할 때 전달되는 값으로, 주로 HTTP 요청 본문에 담겨 전달됩니다. 

Path Variable은 보통 웹 애플리케이션의 동적인 처리를 위해 사용됩니다. 예를 들어, 로그인 요청을 할때 사용자 이름과 비밀번호는 이런 식으로 전달되는 경우가 대부분입니다.

 

🐥잠깐. 동적 처리란?

서버에서 요청을 받아서 그에 따라 동적으로 생성된 HTML, 데이터, 이미지, 동영상 등을 클라이언트에게 보내는 것. 예를 들어, 사용자가 로그인 폼에 정보를 입력하고 제출하면 서버에서는 해당 정보를 검증하고 인증한 후, 로그인 성공 여부에 따라 다른 결과를 보여주는 것이 동적인 처리라고 할 수 있습니다.

흔히 아래와 같은 항목들이 동적 처리의 예시로 일컬어집니다.

1. 사용자 인증과 권한 관리: 사용자 인증 정보를 입력받아 인증하는 과정에서, 서버에서는 입력받은 정보와 데이터베이스에 저장된 정보를 비교하고, 인증된 사용자의 권한을 확인하여 적절한 페이지를 보여줍니다.
2. 게시판: 게시글을 작성하고, 수정하거나 삭제할 수 있는 게시판에서, 서버는 요청된 페이지에 해당하는 게시글 목록을 데이터베이스에서 가져와서 동적으로 생성하고, 사용자가 작성한 게시글을 데이터베이스에 저장합니다.
3. 쇼핑몰: 사용자가 상품을 선택하면, 서버에서는 해당 상품의 재고를 확인하고, 장바구니에 담아둡니다. 사용자가 결제를 요청하면, 서버에서는 결제 수단을 확인하고, 결제 정보를 처리합니다. 결제가 완료되면, 서버에서는 상품의 재고를 감소시키고, 배송 정보를 저장합니다.
4. 검색 엔진: 사용자가 검색어를 입력하면, 검색 엔진은 해당 검색어에 대한 결과를 동적으로 생성합니다. 검색 결과는 서버에서 검색어와 일치하는 문서를 찾아내고, 사용자에게 보여줍니다.

 

🚩Query Parameter

Query Parameter는 URL 끝에 보통 "?"를 붙여 값을 전달하는 매개변수입니다.

Query Strings = Query Parameter = URL Parameter (검색하고 내린 결론… 세세하게 차이가 있을지도 모르겠는데 보통 이 셋을 다 묶어서 비슷하게 부름. ?가 오는 매개변수로.)

 

사용자가 데이터를 전달하는 방법 중 하나로, url 주소에 미리 협의된 데이터를 매개변수를 통해 넘깁니다. 여기서 ? 뒤에 있는 부분을 Query라고 부릅니다. Query는 ‘질문’을 뜻하는 단어인데, ? 라는 기호에 주목하면 이해가 쉬울 것 같습니다.

 

언제 사용? → 정렬, 필터링 할 경우. 특히 정보가 많을 때(페이지네이션, 필터링)

 

query는 주로 검색을 하거나 필요한 필터링 정보 등을 전달하는데 자주 사용됩니다.

/users?id=123   # 아이디가 123인 사용자를 가져온다.

위의 URL에서 "id"는 쿼리의 키, "123"는 값입니다.

query parameters(물음표 뒤에 = 로 연결된 부분)을 url 뒤에 덧붙여 추가적인 정보를 서버 측에 전달합니다. Query Parameter은 경로 뒤에 데이터를 함께 제공하는 식으로 사용하고, 다음과 같이 &로 연결하여 여러 매개변수를 넘길 수도 있습니다.

/post?post_id=6&key1=value1

이처럼 매개변수를 여러 개 보내고 싶으면 &(엔드 연산자)를 붙여가며 추가할 수 있는데, 이때 뭐가 앞에 오느냐 뒤에 오느냐의 정렬 순서는 영향을 주지 않습니다. 

query는 데이터베이스에서 데이터를 조회하거나 수정하기 위해 사용되는 명령어이며, SQL 문장으로 작성됩니다. 이처럼 query를 사용하면 필요한 데이터를 정확하고 빠르게 조회할 수 있습니다.

 

 

 

첨언하자면

구글 Developers에 따르면 크게 두 가지 종류의 url parameters(query parameter)가 있다고 합니다.

 

콘텐츠 수정 매개변수: 페이지에 표시되는 콘텐츠를 수정합니다. 예를 들어 사용자를 'xyz'라는 특정 제품으로 직접 보내려면 (<http://domain.com/?productid=xyz>) 라고 보낼 수 있습니다.

 

고급 추적을 위한 추적 매개변수 (수동적) : 추적을 위해 계정, 캠페인 또는 광고 그룹의 클릭에 대한 정보를 전달합니다. 즉 사용자 활동을 모니터링하는 데 도움이 되는데, URL 매개 변수를 사용하면 분석 플랫폼 (예 : Google Analytics 또는 Adobe Omniture)을 사용하여 항목을 클릭한 사용자의 행동 방식을 이해할 수 있습니다.

 

예: 뉴스레터의 트래픽 추적 https://www.domain.com/?utm_source=newsletter&utm_medium=email

예: 맞춤 URL로 캠페인 데이터 수집

https://www.domain.com/?utm_source=twitter&utm_medium=tweet&utm_campaign=summer-sale

 

출처: https://support.google.com/google-ads/answer/6277564?hl=en

Website Domain Names, Online Stores & Hosting - Domain.com

🎈다 알겠는데, 왜 구분되지? 어떨 때 사용하는가?

본론부터 언급하자면 리소스를 식별하고 싶으면 Path Variable을 사용하고, 정렬이나 필터링을 한다면 Query Parameter를 사용하는 것이 좋습니다.

/users # Fetch a list of users

/users?occupation=programer # Fetch a list of programer user

/users/123 # Fetch a user who has id 123

사용자 입력 값에 따라 다양한 결과를 도출해야 하는 동적 처리를 할 때는 Path variable를 사용하는 것이 좋고, 데이터 조회나 수정과 같은 정적인 처리를 할 때는 Query Parameter를 사용하는 것이 좋다고도 말할 수 있겠네요. 또한 Path variable는 경로(path)를 통해 값을 전달하기에 일반적으로 요청을 보내기 전 값을 알고 있어야 하지만, Query Parameter는 URL 뒤에 값을 붙여 전달하기 때문에 요청을 보내기 전에 값을 동적으로 지정할 수 있다는 점도 차이로 둘 수 있습니다.

 

…흠… 이렇게 말해봤자 와닿지 않으니 바로 예시로 넘어가 봅시다.

1 존재하지 않은 리소스에 id가 들어올 경우, 각각 어떻게 동작할까요?

→ Path Variable 은 경로에 해당하는 페이지가 없으므로 404 에러를 발생시킵니다.

→ 그에 비해 Query Parameter는 서버로 데이터가 넘어가고 해당하는 데이터가 없을 경우엔 따로 에러 핸들링을 해줘야 합니다. 그러니 리소스를 식별해야 하는 상황에서는 Path Variable가 더 적합하다고 할 수 있겠네요.

 

 

2 이번에는 정렬이나 필터링을 할 상황을 생각해봅시다. post에서 penguin 관련 글만 필터링하는 아래와 같은 두 예시가 있습니다. 그런데 post에 penguin 관련 글이 없다면 어떻게 될까요?

post/penguin

post?category=penguin

→ Path Variable 는 404 에러를 발생시킵니다.

→ 반면 Query Parameter 는 빈 리스트를 반환하겠죠.

필터링을 하다 404에러가 발생하는 것은 다소 부적절하므로 정렬이나 필터링을 해야하는 상황에서는 Query Parameter 가 더 적합합니다. 이러한 차이를 고려하여 적절한 방식을 선택하여 URL을 사용하면 됩니다.

 

참고: https://ryan-han.com/post/translated/pathvariable_queryparam/

 

🎈추가적으로, Query Parameter을 쓰는 경우

트랙킹 / 주문하기 / 검색하기 / 식별하기 / 페이지 전환 / 언어 처리 / 걸러내기

 

이 중에서 Searching, sorting, filtering and pagination을 자주 쓰나봅니다.

이러한 일들을 다루기 위해서는 새 API를 만들 것이 아니라 query를 사용하면 됩니다.

 

Sorting 정렬하기: 예를 들어, 컴퍼니 리스트가 있다고 했을때 회사 종류를 분류하고 싶다면, GET/companies 엔드 포인트는 정렬을 위한 매개변수를 받아야 합니다. GET /companies?sort=rank_asc와 같은 엔드 포인트는 컴퍼니를 순위에 따라 정렬해줄 것입니다.

 

Filtering 필터링 하기: 필터링하기 위해서도 query로 보낼 수 있습니다. GET /companies?category=banking&location=india같은 식으로 banking 카테고리에 속하는 컴퍼니들과, 위치가 India인 컴퍼니들을 거를 수 있습니다.

 

Searching 검색하기: 컴퍼니 이름을 리스트에서 검색하고 싶을때, API의 엔드포인트는 GET /companies?search=Digital Mckinsey 이런 식으로 작성되어야 합니다.

 

Pagination 페이지네이션: 데이터가 너무 방대할 때, 데이터를 좀더 원활하게 다루기 위해 작게 나누어야 합니다. 이때 페이지네이션이 큰 도움이 되는데요. GET /companies?page=23 이런 식으로 23번째 페이지에 있는 리스트를 불러올 수 있게 됩니다.

만약 30부터 45까지만 보여주고 싶다면 

/employees?offset=30&limit=15 # returns the employees 30 to 45

이런 식으로도 쓸 수 있습니다.

 

 

그런데 GET 메소드 내부에 너무 많은 query params를 포함했다면 어떻게 될까요?

서버는 414 URI Too long HTTP 상태코드(클라이언트가 요청한 URI가 서버가 해석가능한 URI보다 더 길다)를 보냅니다. 이런 경우엔 params를 request body의 POST 메소드로 보내는 것이 정석입니다.

 

출처: https://www.semrush.com/blog/url-parameters/

https://medium.com/@fullsour/when-should-you-use-path-variable-and-query-parameter-a346790e8a6d

https://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-apihttps://hackernoon.com/restful-api-designing-guidelines-the-best-practices-60e1d954e7c9https://phauer.com/2015/restful-api-design-best-practices/

 

 

🎈query 매개변수가 SEO 문제가 있을 수도 있다?

← 설명은 길고 원문을 읽어보기를 추천…… 

 

대부분의 SEO 친화적인 조언은 가능한 한 URL 매개변수를 멀리할 것을 제안합니다.

매개변수가 아무리 유용하더라도 웹 크롤러의 속도를 저하시키는 경향이 있기 때문이죠.

1. 중복 콘텐츠 : 모든 URL은 검색 엔진에서 독립적인 페이지로 취급되기 때문에 URL 매개변수로 생성된 동일한 페이지의 여러 버전은 중복 콘텐츠 로 간주될 수 있습니다 . 이는 URL 매개변수에 따라 재정렬된 페이지가 원본 페이지와 매우 유사한 경우가 많지만 일부 매개변수는 원본과 정확히 동일한 콘텐츠를 반환할 수 있기 때문입니다.
2. 크롤링 예산 손실 : 간단한 URL 구조를 유지하는 것은 URL 최적화의 기본입니다. 여러 매개변수가 있는 복잡한 URL은 동일한(또는 유사한) 콘텐츠를 가리키는 다양한 URL을 생성합니다. Google Developers에 따르면 크롤러는 웹사이트의 모든 콘텐츠를 인덱싱하는 대역폭 "낭비"를 피하고 낮은 품질로 표시한 후 다음 콘텐츠로 이동할 수 있습니다.
3. 키워드 식인화 : 원본 URL의 필터링된 버전은 동일한 키워드 그룹을 타겟팅합니다. 이로 인해 다양한 페이지가 동일한 순위를 두고 경쟁하게 되며, 크롤러는 필터링된 페이지가 사용자에게 실질적인 가치를 추가하지 않는다고 결정할 수 있습니다.
4. 희석된 순위 신호 : 동일한 콘텐츠를 가리키는 여러 URL을 사용하면 링크 및 소셜 공유가 페이지의 매개변수화된 버전을 가리킬 수 있습니다. 이는 경쟁 페이지 중 검색 쿼리에 대해 순위를 매겨야 하는 페이지를 이해하지 못하는 크롤러를 더욱 혼란스럽게 할 수 있습니다.
5. URL 가독성 저하 : URL 구조를 최적화할 때 URL이 간단하고 이해하기 쉽기를 원합니다. 긴 코드 문자열과 숫자는 계산서에 거의 맞지 않습니다. 매개변수화된 URL은 사용자가 사실상 읽을 수 없습니다. SERP, 뉴스레터 또는 소셜 미디어에 표시될 때 매개변수화된 URL은 스팸성 및 신뢰할 수 없는 것으로 보이므로 사용자가 페이지를 클릭하고 공유할 가능성이 낮아집니다.