오늘은 웹서비스 개발자라면 당연히 알고 있어야 할 핵심 프로토콜!! HTTP에 대해서 공부했다
HTTP는 HyperText Transfer Protocol의 약자이다.
그래서 HyperText Transfer Protocol이 뭔데? 🤔
라는 생각이 들 수 있다. 단어를 하나하나 뜯어 보도록 하자.
1. HyperText
HyperText란 문서와 문서가 링크로 연결되어 있는 것, 즉 문서 내의 특정한 단어가 다른 단어나 데이터베이스와 링크되어 있어 사용자가 관련 문서를 넘나들며 원하는 정보를 얻을 수 있는 형태를 말한다.
2. Transfer
사전적 의미로는 "전송하다" 라는 의미를 가진다. 여기서는
3. Protocol
프로토콜은 협약, 통신규약 이라는 의미를 가진다. 물리적으로 떨어진 컴퓨터끼리 어떻게 HTML 파일을 주고 받을지에 대한 약속이다.
한국인들은 한국 사회의 소통방식(약속)인 한국어로 소통을 하듯 컴퓨터도 컴퓨터끼리의 소통 방법이 필요하다. HTTP가 바로 이러한 소통방식 중 하나이다. 우리가 사용하는 인터넷 상에서 일어나는 소통은 대부분 HTTP 규약을 따른다.
A. 컴퓨터들끼리 HTML파일을 주고 받을 수 있도록 하는 소통 방식 또는 약속이다
HTTP의 핵심은 요청과 응답이다. 앞서 HTTP의 세번째 키워드인 Transfer에 대해서 설명할 때, 전송은 보내는 주체와 받는 주체가 있다고 했다. 보내는 주체는 받는 주체에게 요청을 보내고, 받는 주체는 요청을 보낸 주체에게 응답을 보낸다.
좀 더 이해가 쉽도록 사례를 들어보자면 이렇다. 내가 만약 넷플릭스에 접속해서 보고 싶은 드라마를 찾아 1화를 누른다고 하자, 그 순간 내 랩탑은 넷플릭스의 서버에 요청을 보내는 것이다. "orange is the new black 1화 영상을 보내줘!" 그러면 넷플릭스 서버는 이 요청을 처리해서 다시 요청을 보낸 나의 랩탑에 응답을 보낸다 "자, 여기 요청한 영상을 드립니다!"
state + less = 상태없음!
HTTP에 대한 설명 중 절대 잊어서는 안 될 HTTP의 특징이 바로 Stateless다. stateless를 바로 직역하면 '상태없음'이라는 말이 지만 과연 HTTP에서 상태없음이 무엇인지 직관적으로 다가오지는 않는다.
stateless란?
각 각의 HTTP 통신 (요청/응답)은 독립적이기 때문에 과거의 통신 (요청/응답)에 대한 내용을 전혀 알지 못한다. 는 뜻이다
Q. 이전의 상태를 전혀 알지 못한다는 것은 무엇을 의미할까?
A. 매 통신마다 필요한 모든 정보를 담아서 요청을 보내야 한다는 것이다.
사례를 들어보자, 쿠팡에 로그인을 했다고 하자 그리고 나서 물건을 둘러보다 맘에 드는 스피커를 장바구니에 추가하기 위해서 장바구니 버튼을 누르면 나의 랩탑은 쿠팡 서버에 '이 스피커를 장바구니에 담아줘!'라는 요청을 보낼 것이다. 그런데 이 때, 쿠팡서버는 과거의 통신 내용을 전혀 기억하지 못하기 때문에 '나는 이미 로그인 했다는 사실'을 같이 보내야만 쿠팡 서버가 '아 아까 로그인한 이 유저가, 스피커를 장바구니에 담으려고 하는구나'라고 알 수 있게 되는 것이다.
따라서, 여러번의 통신(요청/응답)의 진행과정에서 연속된 데이터 처리가 필요한 경우 (ex. 온라인 쇼핑몰에서 로그인 후 장바구니 기능)를 위해 로그인 토큰, 또는 브라우저의 쿠키, 세션, 로컬스토리지 같은 기술이 필요에 의해 만들어졌다.
HTTP 요청은 프론트엔ㄷ(클라이언트)에서 백엔드(서버)에 일(데이터 처리)을 시작하게 하기 위해 보내는 메세지다. 이 메세지의 구조는 크게 세 부분으로 구성되어 있다.
GET /login HTTP/1.1
해석: GET 메소드로 login 이라는 요청 타겟에 HTTP 1.1 버전으로 요청을 보내겠다!
Key: Value 값으로 되어있다 (JavaScript의 객체, Python의 딕셔너리 형태라고 보면 된다)
자주 사용되는 Headers 의 정보에는 다음이 있다
Headers: {
Host: 요청을 보내는 목표(타겟)의 주소. 즉, 요청을 보내는 웹사이트의 기본 주소가 된다
(ex. www.apple.co.kr)
User-Agent: 요청을 보내는 클라이언트의 대한 정보 (ex. chrome, firefox, safari, explorer)
Content-Type: 해당 요청이 보내는 메세지 body의 타입 (ex. application/json)
Content-Length: body 내용의 길이
Authorization: 회원의 인증/인가를 처리하기 위해 로그인 토큰을 Authroization 에 담는다
}
ex) 로그인 시에 서버에 보낼 요청의 내용
Body: {
"user_email": "jun.choi@gmail.com"
"user_password": "wecode"
}
HTTP 규약에 따른 응답의 구조 또한 크게 세 부분으로 구성되어 있다.
- HTTP Version: 요청의 HTTP버전과 동일
- Status Code: 응답 메세지의 상태 코드
- Status Text: 응답 메세지의 상태를 간략하게 설명해주는 텍스트
HTTP/1.1 404 Not Found
해석: HTTP 1.1 버전으로 응답하고 있는데, 프론트엔드에서 보낸 요청(ex. 로그인 시도)에 대해서
유저의 정보를 찾을 수 없기 때문에(Not Found) 404 상태 메세지를 보낸다.
HTTP/1.1 200 SUCCESS
해석: HTTP 1.1 버전으로 응답하고 있는데, 프론트엔드에서 보낸 요청에 대해서 성공했기 때문에
200 상태 메세지를 보낸다.
> 여기서 잠시 자주 볼 수 있는 status codes에 대해서 알고 넘어가자!
status Code의 숫자에 각각의 의미가 내포되어 있다. 이 코드만 보아도 응답이 제대로 됐는지 안 됐는지를 파악할 수 있다.
Response Status Codes
200: OK
201: Created
400: Bad Request
401: Unauthorized
403: Forbidden
404: Not Found
500: Internal Server Error
보다 더 자세한 HTTP Response Status Codes MDN link
다만, 응답에서만 사용되는 헤더의 정보들이 있다. (ex. 요청하는 브라우저의 정보가 담긴 User-Agent 대신, Server 헤더가 사용된다.)
ex) 로그인 요청에 대해 성공했을 때 응답의 내용
Body: {
"message": "SUCCESS"
"token": "kldiduajsadm@9df0asmzm" (암호화된 유저의 정보)
}