HTTP는 웹서비스 개발자라면 당연히 알고 있어야 할 핵심 프로토콜이다.
HTTP 통신은 어떻게 구성되고 사용되어야 하는지 알아보자
HTTP
HyperText Transfer Protocol(HTTP)
프로토콜이다.
HyperText
HTML: 문서와 문서가 '링크'로 연결되도록 하는 태그로 구성된 언어
링크 주소에 따른 데이터를 불러온다
HTML은 웹페이지를 만들기 위해서 웹브라우저 위에서 동작하는 언어를 뜻함
이 HTML로 만든 웹페이지를 어떻게 주고 받을 것인가?
Transfer
전송
다른 컴퓨터에게 전송
전송은 보내는 주체와 받는 주체가 있다는 것이 큰 특징
Protocol
프로토콜은 '협약', '통신 규약' 이라는 의미를 가짐
어떻게 컴퓨터끼리 html 파일을 주고받을지에 대한 약속
통신 시스템이 데이터를 교환하기 위해 사용하는 통신 규칙, 약속
컴퓨터들끼리 HTML파일을 주고받을 수 있도록 하는 소통방식 또는 약속이다.
👉 면접 때 물어보면 이거 한 문장으로 대답할 수 있어야 됨
HTTP의 두가지 특징
1. Request / Response (요청 / 응답)
HTTP 통신의 핵심은 '요청'과 '응답'이다.
전송을 했을 때 request를 보내면 항상 response를 받아야 함
👉 완전한 HTTP 통신이 이루어짐
request 했는데 response가 없는 경우
👉 불완전함. 실패한 거.
request가 갔으면 response가 다시 돌아와서 찍혀야 'HTTP 통신을 했다'라고 말할 수 있음
404 Not Found도 응답해준거임
아예 응답이 없는 경우는 로딩 계속 돌고 아무 일 없을 때가 실패한 거
요청과 응답이 잘 이루어져야 함
2. Stateless
State(상태) + less(없음)
상태를 저장하지 않는다.
매 통신마다 필요한 모든 정보를 담아서 요청을 보내야 한다.
이어서 일을 하고 싶으면 그거에 대한 정보까지도 같이 보내야 됨
'로그인을 했다'라는 사실을 로그인 된 상태라는 걸 알아야 되잖아요
지금 로그인 정보를 보내고 응답을 받아도 통신 요청을 하면 로그인한 사용자인 걸 모름
로그인한 사용자라는 걸 다른 방법으로라도 알아내야 함
그걸 위한 방법을 만듦
같은 사용자의 요청이란 걸 지속적으로 알려고
로그인 토큰 또는 브라우저의 쿠키, 세션, 로컬스토리지 같은 기술이 만들어짐
Request / Response
통신이라고 하지만 이것도 결국 코딩이다. 프로그램화 된 방법.
데이터를 주고 받기 위한 스펙을 배우고 있는 거
HTTP 프로토콜이라는 게 어떤 방식으로 규정되어 있고 내가 이걸 어떻게 써야 정확히 전달하고 전달받을 수 있는지 그걸 지금 배우는 거
실제 프로젝트를 진행할 때, 프론트엔드에서 백엔드에게 데이터를 요청하고 백엔드는 요청을 처리해서 응답을 준다.
1. Request 메시지 구조
요청은 사실 그저 메시지에 불과하다.
데이터를 달라든지, 데이터를 기록해달라든지, 데이터를 삭제를 해달라든지
통신을 통해서 요청하는 거
메세지의 구조는 크게 세 부분으로 구성되어있다. (1. Start Line, 2. Headers, 3. Body)
1. Start Line
요청의 첫 번째 줄에 해당한다. 이 시작줄도 세 부분으로 구성되어 있다.
개발자 도구로 볼 수 있음
🔹 HTTP Method
해당 요청이 의도한 액션을 정의하는 부분. 주로 GET, POST, DELETE가 많이 쓰임
🔹 Request target
해당 request가 전송되는 목표 url
어느 url 경로에다가 요청을 하고 있는지 타겟 포인트를 명시해준다
내가 지금 어디에 요청할 거야 라는 의미
세부 url. 상세 경로.
🔹 HTTP Version
말 그대로 사용되는 HTTP 버전을 뜻한다. 주로 1.1 버전이 널리 쓰임
범용적으로 쓰이는 건 1.1이지만 2.0 3.0도 나와있음
버전에 따른 성능 차이, 방식 차이 있음
GET /login HTTP/1.1
login 이라는 요청 타겟에 HTTP 1.1 버전으로 요청을 보내겠다!
HTTP 1.1 버전으로 login 이라는 주소에 데이터를 달라고 요청하는 거
↑ 내가 직접 이걸 만들진 않고 브라우저가 이미 이 일을 해주고 있음
브라우저에서 주소 입력하는 순간 이미 이런 일이 일어나고 있다
2. Headers
해당 요청에 대한 추가 정보(메타 데이터)를 담고있는 부분
추가적인 메타 정보
Key: Value 값으로 되어 있다.
Headers: {
Host: 요청을 보내는 목표(타겟)의 주소. 즉, 요청을 보내는 웹사이트의 기본 주소가 된다
(ex. www.apple.co.kr)
User-Agent: 요청을 보내는 클라이언트의 대한 정보 (ex. chrome, firefox, safari, explorer(X))
Content-Type: 해당 요청이 보내는 메세지 body의 타입 (ex. application/json)
Content-Length: body 내용의 길이
Authorization: 회원의 인증/인가를 처리하기 위해 로그인 토큰을 Authroization 에 담는다
}Content-Type: 해당 요청이 보내는 메세지 body의 타입 (ex. application/json)
javascript 오브젝트 데이터 타입: Key와 Value 되어 있는 캐시 자료 구조
지금은 거의 json을 많이 씀
Content-Length: body 내용의 길이
Authorization: 인증/인가
로그인 했을 경우 매개가 되는 토큰 같은 걸 받게 되는데 그걸 Authorization에 담음
3. Body
Body: 해당 요청의 실제 내용.
딕셔너리 형태
Key를 감싸는 건 무조건 큰따옴표
요소마다 콤마 써주기
ex) 로그인 시에 서버에 보낼 요청의 내용
Body: {
"user_email": "jun.choi@gmail.com",
"user_password": "wecode"
}Response 메시지 구조
Request랑 첫 줄만 다름
어떤 상태 코드를 받았느냐가 중요
response 구조도 세 부분으로 구성되어 있다.
1. Status Line
🔹 HTTP Version
Request의 HTTP버전과 동일
검색해보면 다양한 응답 번호 나옴..
🔹 Status Code
백엔드 request 받아서 response 주는
백엔드가 응답코드 더 잘 알고 있어야 됨
프론트엔드도 응답코드를 봤을 때 무슨 에러인지 알아야 됨
status code를 내보내는 사람이 명확하게 잘 규정을 해야 되기 때문에 더 잘 알고 있어야 함
HTTP/1.1 200 SUCCESS (잘 됐다, 성공했다)
HTTP/1.1 404 Not Found
없는 html 문서를 조회하려고 했을 때
없는 경로를 호출했을 때
백엔드가 제일 싫어하는 에러 응답 코드는 500 (서버 에러)
http status code 검색하면 많이 나옴
HTTP 상태 코드 - HTTP | MDN
https://developer.mozilla.org/ko/docs/Web/HTTP/Status
2. Headers
Headers: request의 헤더와 동일한데 차이가 있는 건
요청하는 브라우저의 정보가 담긴 User-Agent 대신, Server 헤더가 사용된다. 운영하고 있는 웹 서버의 버전이 나올 수도 있음. 파이썬 웹 서버 엔진이 표시되기도 함.
3. Body
항상 데이터 규격은 json
주고 받는 데이터의 형식은 json
그걸 꼭 기억해두기
request response 차이 기억하기!!
request 시에는 Method가 중요하고
response 시에는 어떤 상태 코드를 받았으냐가 중요
HTTP Request Methods
Method는 request할 때 쓰는 도구
request를 할 때 내가 어떤 행위를 할 거다 라는 걸 말해줌
자주 사용되는 HTTP 통신 메소드 세 가지
1. GET
2. POST
3. DELETE
GET
데이터를 서버로부터 받아오기만 할 때 사용함
데이터를 서버에 달라고 요청하는 거랑 같음
제일 많이 씀
주소를 치고 요청할 때 하는 게 다 GET
브라우저로 일반 동작할 때도 거의 GET
스타벅스에 제품 정보 보이는 것도 다 GET 메소드로 요청해서 브라우저에 표시되는 거
장바구니에 담은 제품을 조회
POST
데이터를 보낼 때
데이터를 입력시키고 싶을 때
데이터를 Body에 담아서 보내줌
데이터 추가 됐을 때 추가가 성공하면 주는 응답코드 201 SUCCESS
데이터를 생성/수정할 때 주로 사용되는 메소드
DELETE
특정 데이터를 서버에서 삭제 요청을 보낼 때 쓰는 메소드
Delete는 body가 있으면 안 됨
body를 전송하면 안 됨
삭제가 완료 되면 응답코드 201 SUCCESS
장바구니에서 삭제 버튼을 누르면 작동
Headers: {
"HOST": "https://www.apple.com/kr"
"Authroization": "kldiduajsadm@9df0asmzm" (유저가 본인임을 증명할 수 있는 인증/인가 토큰)
}
Body: {
productId: 30 👈 Body 지우기
}프론트분들이
바디 데이터 받은 걸 가지고 경로에 해당하는 주소 로직에서 정보를 ㅂ다앗을 때 이거를 등록을 시켜서 응답을 줘야 함
빠르면 이번주 다음주에 하고 있을 일
Response Status Codes
HTTP 상태 코드 - HTTP | MDN
https://developer.mozilla.org/ko/docs/Web/HTTP/Status
500: Internal Server Error
백엔드 개발자들이 싫어하는 코드
백엔드 책임
이런 에러들을 체크해서 리턴이 적절하게 될 수 있도록 바꾸는 거
Review
1. HTTP 는 컴퓨터 끼리의 소통을 위한 통신규약이다.
2. HTTP 통신은 Request(요청)과 Response(응답)으로 이루어 진다.
3. HTTP 통신의 매 요청과 응답은 이전 상태를 알지 못 한다. (Stateless)
Request 메세지 구조 & Response 메시지 구조 잘 정리해서 이해하기
메소드엔 뭐가 있는지 메소드는 어떻게 써야 하는지 정확히 알고 있기
백엔드들은 에러가 나거나 잘못된 요청을 받았을 때 어떤 식으로 리턴 해줘야 되느냐
거기에 맞는 status 코드를 적절하게 프론트에게 전달을 해줘야
프론트 분들이 내가 뭘 잘못했는지 알 수 있음
제일 최악은 그런 게 잘 안 돼서 500 에러가 나갔고 도대체 어디서부터 뭐가 잘못됐는지 찾아내야 되는 게 백엔드 개발자가 가끔씩 힘들어지는 이유
get과 delete는 body의 내용을 담지 않음
물리적으로 담을 수는 있음.
url 안에 특정 데이터의 아이디
데이터를 가져오는 건 무조건 get이구요
단순히 조회를 위해서는 POST를 쓰지 않아요
항상 데이터 조회는 GET으로 해야한다
전송을 위해서만 POST를 써야 해요
요즘은 push patch 보다 post를 선호
각각 메소드가 의미하는 바와 사용하는 방법
처음부터 이래도 되고 저래도 된다는 느낌으로 쓰면 나중에 문제가 됨
처음에는 엄격하게 각 메소드는 이렇게 정의돼서 동작되어야 한다 라는 규칙을 가지고 접근을 해야 함
개발자 도구를 보면 Network 패널
터미널에서 http를 호출하기 가장 편한 도구
http -v www.naver.com
GET / HTTP/1.1
API 호출하는 거 테스트 하는 사이트 있음
호출해보면 체감이 됨
나중에는 도구로 호출하는 게 아니라 코딩으로 백엔드가 만들어 놓은 경로에 호출 하는 거
