TIL | HTTP

gemma. K·2020년 10월 29일

HTTP란

HTTP는 HyperText Transfer Protocol의 약자이다.

1. HyperText

HyperText란 하나의 문서가 참조를 통해 다른 문서와 연결될 수 있도록 하는 텍스트이다. HTML(HyeprText Markup Language)도 마찬가지로 참조가 가능하도록 설계되어 있기 때문에 css, js, img 파일들과 연동 가능하도록 하는 언어(태그)로 구성된 것으로 볼 수 있다.

2. Transfer

transfer의 사전적 의미는 '전송하다' 라는 뜻으로 '전송'에는 '물건이나 편지 따위를 보낸다'라는 의미가 내포되어 있다.

3. Protocol

프로토콜은 협약, 통신 규약이란 뜻을 지니고 있다. 물리적으로 떨어진 컴퓨터들을 어떻게 서로 통신 가능하도록 만들 것인지에 대한 약속이다.

HTTP는 컴퓨터들끼리 이미지, 동영상, 문서 등의 데이터를 서로 주고 받기 위한 소통 방식 및 약속(규약)

HTTP의 특징

1. Request(요청) & Response(응답)

HTTP는 요청과 응답으로 이루어져 있다. 사람과 사람 간의 소통이 있듯 우리도 컴퓨터를 사용할 때 HTTP를 이용하여 요청을 하고 그에 대한 답을 받는다. 예를 들어, 웹 브라우저를 열고 넷플릭스 사이트로 접속한다. 그리고 보고 싶은 영화를 골라 클릭한다. 매 순간 순간 마다 컴퓨터는 내가 원하는 것을 HTTP를 사용해 요청하고 응답을 받도록 돕는다.

소통은 '요청'과 '응답'으로 🤟🏻

2. Stateless (무상태)

HTTP의 가장 큰 특징이라 볼 수 있는 Stateless. 말 그대로 상태가 없다는 뜻인데 HTTP는 상태가 없다. 그렇다면 어떻게 통신을 하냐고 물을 수 있다. HTTP는 통신을 한다는 기본 기능을 가지고 있지만 요청과 응답이 없는 경우 아무런 과거의 요청, 응답, 정보들을 기억하지 못한다. 그래서 http 통신을 위해서는 매 통신마다 필요한 정보를 담아 보내야 한다.
그래서 만일 여러번의 통신(요청/응답)의 진행과정에서 연속된 데이터 처리가 필요한 경우(ex. 온라인 쇼핑몰에서 로그인 후 장바구니 기능)를 위해 로그인 토큰 또는 브라우저의 쿠키, 세션, 로컬스토리지 같은 기술이 필요하다.

Request & Response

http request와 response의 개괄적인 구조를 보기 위해서는 웹 브라우저 개발자 도구의 Network 패널에서 확인 가능하다. Request은 프론트(클라이어트)에서 백엔드(서버)에 데이터 처리를 시작하도록 하는 메시지이다. 이 메시지는 크게 세 가지로 나누어 질 수 있다.

Request의 구조

1. Start Line

요청의 첫번째 줄에 해당한다. 이 시작 줄도 세 부분으로 구성되어있다.

1. HTTP Method: 해당 요청이 의도한 액션을 정의하는 부분. 주로 GET, POST, DELETE가 많이 쓰임
2. Request target: 해당 request가 전송되는 목표 url 
3. HTTP Version: 말 그대로 사용되는 HTTP 버전을 뜻한다. 주로 1.1 버전이 널리 쓰임!

2. Headers

key와 value 값의 형태로 되어 있으며(js의 object, python의 dictionary) 해당 요청에 대한 추가 정보(메타 데이터)를 담고있는 부분이다.

Headers: {
  Host: 요청을 보내는 목표(타겟)의 주소 (ex. www.apple.co.kr)
  User-Agent: 요청을 보내는 클라이언트의 대한 정보 (ex. chrome)
  Content-Type: 해당 요청이 보내는 메세지 body의 타입 
  (ex. application/json)
  Content-Length: body 내용의 길이
  Authorization: 회원의 인증/인가를 처리하기 위해 로그인 토큰이 담김
}

3. Body

Body에는 해당 요청의 실제 내용이 담기며 주로 사용되는 메소드는 POST다. 아래 예시는 사용자가 로그인 하는 경우이다.

Body: {
	"user_email": "jun.choi@gmail.com"
	"user_password": "wecode"
       }

Response의 구조

Response 또한 Request처럼 메시지의 일종이다. 반대로 Response는 백(서버)에서 프론트(클라이언트)로 요청에 대한 처리 상태를 전달하는 것이다. 응답 또한 세 부분으로 구성된다.

1. Status Line

응답의 상태 줄이다. 응답은 요청에 대한 처리상태를 클라이언트에게 알려주면서 내용을 시작한다. 마치, 편지의 응답에 "응. 잘 지냈어" 라고 안부 인사를 건네는 것과 같다. 응답의 Status Line 도 세 부분으로 구성된다.

1. HTTP Version: 요청의 HTTP버전과 동일
2. Status Code: 응답 메세지의 상태 코드
3. Status Text: 응답 메세지의 상태를 간략하게 설명해주는 텍스트


HTTP/1.1 404 Not Found
해석: HTTP 1.1 버전으로 응답하고 있는데, 프론트엔드에서 보낸 요청(ex. 로그인 시도)에 대해서 유저의 정보를 찾을 수 없기 때문에(Not Found) 404 상태 메세지를 보낸다.

HTTP/1.1 200 SUCCESS
해석: HTTP 1.1 버전으로 응답하고 있는데, 프론트엔드에서 보낸 요청에 대해서 성공했기 때문에 200 상태 메세지를 보낸다.

2. Headers

요청의 헤더와 동일하다. 응답의 추가 정보(메타 데이터)를 담고있는 부분이다. 다만, 응답에서만 사용되는 헤더의 정보들이 있다. (ex. 요청하는 브라우저의 정보가 담긴 User-Agent 대신, Server 헤더가 사용된다.)

2. Body

요청의 Body와 일반적으로 동일하다. 요청의 메소드에 따라 Body가 항상 존재하지 않듯이. 응답도 응답의 형태에 따라 데이터를 전송할 필요가 없는 경우엔 Body가 없을 수도 있다. 가장 많이 사용되는 Body 의 데이터 타입은 JSON(JavaScript Object Notation) 이다.

ex) 로그인 요청에 대해 성공했을 때 응답의 내용
Body: {
	"message": "SUCCESS"
	"token": "kldiduajsadm@9df0asmzm" (암호화된 유저의 정보)
}

HTTP method

클라이언트에서 서버 쪽으로 요청을 보내는 방식
주어진 리소드에 대해 수행하길 원하는 행동을 나타냄
메서드에 따라 safe(안전성), idempotent(멱등성: 모든 요청에 항상 같은 응답을 하는가), cacheable(캐싱 가능)이 다름

GET

주로 데이터를 읽거나 검색할 때, 사용되는 메소드로 http 명세에 따르면 읽고, 검색할 때만 사용되고, 수정할 때는 사용되지 않는다.
데이터를 받기만 할 뿐, 클라이언트 측에서는 어떠한 데이터도 넘기지 않는다.
idempotent한 성질을 가짐. 여러 요청에 응답이 변하지 않고 항상 같다.
form data는 URL로 인코딩되어 action URL에 query string parameters로 전달된다. 그러므로 보안이나 개인정보, 중요한 데이터에 대한 요청인 경우, get 메소드를 사용하지 않는다. (다시 말하면, 필요한 리소스에 대한 데이터가 url에 나타난다. 누구나가 민감한 데이터에 접근 가능하다.)

POST

주로 새로운 리소스를 생성하기 위한 용도로 사용되는 메서드
get과는 반대로 idempotent하지 않다. 즉, 같은 요청에 항상 같은 응답을 받을 수 있지 않다.
HTTP POST 요청은 클라이언트에서 서버로 전송할 때 추가적인 데이터를 body에 포함 가능하다.

DELETE

리소스를 삭제하는 데에 사용되는 메서드
성공하면 200 (ok), 주로 204 (no content)가 실패 응답으로 나타남
안전성의 문제로 비활성화된 메서드

PUT

클라이언트에서 넘어온 식별자를 통해 db에 존재하는 데이터를 전체 수정(update)하는 메서드
만약 존재하지 않는 데이터라면 생성(create)하고 201(created)으로 응답함
idempotent한 성질을 가짐. 여러 번의 요청에도 항상 같은 응답.

PATCH

put과는 달리 patch는 데이터의 '일부'수정(update)에 사용된다.
put은 자원의 모든 컬럼을 수정하기 때문에 모든 필드가 필요하지만 patch는 일부 수정하기 때문에 모든 필드의 정보가 필요하지 않다.

Response Status Code

실제 프로젝트를 진행할 때 가장 많이 보게 될 응답의 상태 코드 들이다. Status Code의 숫자에 각각 의미가 내포되어 있다. 이 Status Code 만 보아도 응답이 제대로 됐는지 안 됐는지를 파악할 수 있다.

200: OK

가장 자주 보게되는 Status Code
문제없이 요청에 대한 처리가 백엔드 서버에서 이루어지고 나서 오는 응답코드
우리는 모두 200 OK 를 원한다

201: Created

무언가가 잘 생성되었을 때에(Successfully Created) 오는 Status Code
대게 POST 메소드의 요청에 따라 백엔드 서버에 데이터가 잘 생성 또는 수정 되었을 때에 보내는 코드

400: Bad Request

해당 요청이 잘못되었을 때 보내는 Status Code
주로 요청의 Body에 보내는 내용이 잘못되었을 때 사용되는 코드

401: Unauthorized

유저가 해당 요청을 진행하려면 먼저 로그인을 하거나 회원가입이 필요하다는 의미

403: Forbidden

유저가 해당 요청에 대한 권한이 없다는 뜻
접근 불가능한 정보에 접근했을 경우

404: Not Found

요청된 URI가 존재하지 않는다는 의미

500: Internal Server Error

서버에서 에러가 났을 때의 Status Code
API 개발을 하는 백엔드 개발자들이 싫어하는 코드 🤯 (프론트 잘못이 아니라는 것을 알 수 있는 코드)

gemma. K

이전 포스트

TIL | python modules & packages

다음 포스트

TIL | HTTP

HTTP란

1. HyperText

2. Transfer

3. Protocol

HTTP의 특징

1. Request(요청) & Response(응답)

2. Stateless (무상태)

Request & Response

Request의 구조

1. Start Line

2. Headers

3. Body

Response의 구조

1. Status Line

2. Headers

2. Body

HTTP method

GET

POST

DELETE

PUT

PATCH

Response Status Code

200: OK

201: Created

400: Bad Request

401: Unauthorized

403: Forbidden

404: Not Found

500: Internal Server Error

TIL | python modules & packages

TIL | DataBase & ERD

0개의 댓글