위클리 페이퍼

쿼리 / 요청 응답

sgyeon 2025. 1. 27. 16:11
반응형
SMALL

 

먼저 쿼리(Query)란 직역하면 명사로는 의문, 문의, '물음표'를,

동사로는 질문하다를 뜻 합니다.

 

하지만 저희가 찾고자 하는 쿼리의 내용은 이게 아니죠.

아래 내용을 통해 URL 내의 쿼리가 무엇인지 더 자세히 알아봅시다.

 

강의에서 배운 내용

* 추가적인 요청사항을 적는 곳

* ? 문자로 시작을 하고 여러 개를 사용할 때는 & 구분

 

다시 말해 URL의 구성 요소 중 '쿼리(query)'는 서버로 전달할 혹은 전달 받은 추가 데이터를

나타내며, 보통 '?' 문자 뒤에 위치합니다.

여러 개의 데이터를 전달할 때는 각 쿼리 매개변수를 '&'로 구분합니다.

 

예시 1.

https://www.youtube.com/watch?v=N8wu4JLcgq8

위 링크는 유튜브 영상의 링크이고,

쿼리를 말하기 앞서 다른 구성 요소도 차근차근 분석해 보려 합니다.

 

https://라는 Scheme(스킴),

 

그 뒤에 www.youtube.com라는 Host(호스트)가 붙습니다.

 

스킴과 호스트까지가 보통 우리가 아는 메인 페이지 링크라고 할 수 있습니다.

 

이후에 붙는 /watch는 Path(패스)이며 영상 시청을 할 수 있는 곳을 의미하는 것 같습니다.

 

유튜브 내에 패스의 예시입니다.

 

/results - 일정 키워드를 입력한 검색 '결과'를 나타내는 것 같습니다.

/@crushofficial - Crush의 유튜브 채널이며 아이디가 패스가 되는 것으로 보입니다.

 

watch뒤에 ?v=N8wu4JLcgq8 Query(쿼리)에 해당하는데요.

이는 영상이 유튜브 내에서 지정한 특정 일련번호로 변환 된 것 같습니다.

 

다른 링크를 알아보도록 합시다.

 

 

예시 2.

https://search.naver.com/search.naver?where=nexearch&sm=top_hty&fbm=0&ie=utf8&query=query

 

? 뒷 부분인 ?where=nexearch&sm=top_hty&fbm=0&ie=utf8&query=query

쿼리에 해당하죠.

 

뒷부분의 내용은 아마 지정하기 나름인 것 같으나 몇 개는 알 것 같기도 하고 애매모호하여 GPT의 도움을 조금 빌려보았습니다.

 

  • where=nexearch: 검색 방식 또는 대상. 여기서는 네이버 통합검색(nexearch)을 나타냅니다.
  • sm=top_hty: 사용된 검색 모듈. top_hty는 상단 검색창에서 입력한 경우를 의미합니다.
  • fbm=0: 특정 검색 옵션 설정. (여기서는 기본값 0으로 설정되어 있습니다.)
  • ie=utf8: 입력된 데이터의 인코딩 방식. utf8은 유니코드 표준 UTF-8 인코딩을 의미합니다.
  • query=query: 사용자가 검색창에 입력한 검색어. 여기서는 query라는 단어를 검색했다는 것을 나타냅니다.

+ 만약 codeit을 검색했다면 query=codeit라는 결과값이 나왔겠죠.

 

라고 합니다.

 

배운 내용에서 예시를 들어보자면

우리가 fetch함수를 통해 url데이터를 가져옵니다. 아래 링크를 기반으로 보았을 때,

"https://learn.codeit.kr/api/color-surveys?limit=1&mbti=INTJ"

 

이는 코드잇에서 제공하는 컬러서베이에 내장되있는 데이터를

fetch함수를 통해 말 그대로 가져올 수 있는데요.

 

다시 쿼리의 내용으로 돌아가 limit=1&mbit=INTJ 에 해당하는 부분을 볼 수 있습니다.

쿼리의 위치는 이제 정확히 하시겠죠.

 

이 중 limit = 1표시하는 데이터를 한 개로 제한 한다는 의미입니다.

다시 말해 결과를 한 개만 가져온다고 보시면 되겠습니다.

limit값을 10을 주면 데이터가 10개가 표시가 되겠죠.

 

mbti=INTJ는 컬러서베이 안에 있는 수 많은 데이터 중 'mbti'가 'INTJ'에 해당하는 속성을 가져온다는 것을 의미합니다.

 

추가적으로 offset이라는 것도 존재하는데 이는 offset값 만큼의 데이터를 넘기고 이후의 데이터를 가져온다는 것을 의미합니다.

 

다시 말해 1부터 20까지의 데이터가 있다고 칩시다. 이에 offset값으로 10을 주고, limit 값을 10을 주면 11부터 20이 출력되겠죠.

 

일단 해당 fetch내 URL을 node로 실행시켜보면 다음과 같은 결과 값이 나옵니다.

{
createdAt: 1737622053000,
updatedAt: 1737622053000,
colorCode: '#2596BE',
id: 94305,
mbti: 'INTJ'
}

 

http 요청 방식으로 대게

GET 요청과 POST요청을 많이 접하는 것 같습니다.

 

GET 요청

  • 서버로 데이터를 보내지 않고 정보를 요청할 때 사용하는 방식
  • 데이터는 URL의 쿼리에 해당하는 부분에 기술 혹은 포함 됨.

 

ex) 네이버에 codeit을 검색하게 되면 뒤 쿼리 부분에

?query=codeit의 형태로 나타나게 됨.

주로 검색, 조회, 뉴스 등의 형태로 사용이 된다 보면 됨.

 

POST 요청

  • 서버로 데이터를 보낼 때 사용
  • 요청사항을 Body에 적어 제출

 

ex) 회원가입, 로그인 등의 보안 혹은 민감한 정보 전송에 적합함.

 

이후 응답은 주로 상태코드, 헤더, 바디의 형태로 오게 되는데,

상태 코드는

 

200대 (성공):

200 OK: 요청이 성공적으로 처리 됨.

201 Created: 새로운 리소스가 성공적으로 생성.

 

400대 (클라이언트 오류)

400 Bad Request: 요청이 잘못 됨.

404 Not Found: 리소스를 찾을 수 없음.

 

500대 (서버 오류)

500 Internal Server Error: 서버에 처리 중 오류 발생.

등으로 나눠볼 수 있습니다.

 

주로 우리가 사이트의 접근이 잘못 되어 오류가 발생했을 때 500대 에러를 많이 볼 수 있고,

프로그램이나 어플을 다운 받을 때 기한이나 파일이 만료 되었을 때 404에러를 많이 접할 수 있었을 것 입니다.

 

나머지 헤더와 바디에 관한 응답은 크롬 개발자의 Network 탭에서 자세한 내용을 확인 할 수 있습니다.

 

반응형
LIST