Python Backend - Study Notes 4

날짜: 2022.03.06

 

[4장: HTTP의 구조 및 핵심 요소]

 

 

HTTP = HyperText Transfer Protocol

 

HyperText란 HTML (HyperText Markup Language)의 일부로 웹에서 사용자가 보는 내용물을 의미하며, frontend 내용물이라고 생각하면 편하다. 클라이언트가 사용하는 웹과, 데이터를 담고 있는 클라이언트 서버, 그리고 API를 담고 있는 백엔드 서버, 이 3가지가 통신하기 위해서 정해놓은 일종의 통신 규칙이자 틀을 HTTP라고 한다. HTTP는 기본으로  [client → server] 방향으로 가는 HTTP Request와 [server → client] 방향으로 가는 HTTP Response 가 있다. Request는 쉽게 말해 클라이언트가 데이터 정보나 API 기능을 사용하고 싶다고 서버에 말하는 것이고, response는 request에 대한 서버의 답변이다.

 

Y’all probably know request & response? Simple English.

 

위의 그림이 기본적인 HTTP request (요청) & response (응답) 구조이다. 추가로 알아야 될 사항이 있다면 HTTP는 “STATELESS”이라는 점이다. HTTP는 클라이언트와 서버가 통신을 주고받는 상태인데, 모든 통신들이 독립적이라는 것이다. 예를 들어 내가 어제 서버에 요청한 HTTP protocol과 지금 서버에 요청하고 있는 HTTP protocol은 서로의 존재 여부를 모른다는 것이다. STATELESS의 장점은 한결 간결해진 서버의 디자인이다. 모든 HTTP 통신 간에 진행과 연결 상태를 저장/관리할 필요가 없어졌기 때문이다. 단점으로는 클라이언트가 HTTP 요청을 보낼 때마다 API가 필요로 하는 데이터를 매번 보내야 하는 것이다 (물론 이것을 해결할 방법이 있다 hint: data base). 이제 HTTP request와 response를 각각 요소별로 다룰 것이다.

 

[HTTP Request (요청)]

HTTP Request는 3개의 부분으로 구성된다.

 

① Start Line (HTTP Method)

② Header (accept, connection etc)

③ Body (JSON data)

 

개발자가 주로 지정하는 부분은 “HTTP method”, “Header 일부”, 그리고 “Body”이다.

 

[Request 1. Start Line]

 

 

위의 HTTP Request 터미널 라인을 3개의 요소로 쪼개서 다룰 것이다.

 

① “GET”은 HTTP Method이다. 서버에 어떤 통신 액션을 원하는지 지정해주는 것이다. GET은 여러개의 HTTP Method 중 하나이다. “GET” 말고도 다음과 같은 HTTP Method들이 있다.

1. GET: 가장 많이 사용되는 method 중 하나로 서버에 있는 데이터를 가지고 올때 주로 사용하는 method이다.
2. POST: 데이터를 생성, 수정, 삭제 할 때 사용된다. GET과 POST가 가장 많이 사용된다.
3. OPTIONS: API의 엔드포인트에서 허용하는 method 종류에 무엇이 있는 알고 싶을 때 사용하는 method이다. 엔드포인트에서 허용되는 method는 API 개발 측 (백엔드)에서 지정해 놓은 HTTP Protocol이기 때문에, 지정되지 않은 HTTP Request를 보내면 “405 Method Not Allowed” 응답을 서버에서 받게 될 것이다.
4. PUT/DELETE: 각각 데이터를 새로 생성하거나 삭제할 때 보내는 요청인데 대부분의 경우 POST를 사용해서 처리하기 때문에 이용 빈도가 낮다. 

② “/ping” 은 Request Target이라고도 하며 HTTP Request의 목적 주소지를 의미한다.

③ “HTTP/1.1”은 HTTP 버전 정보로 대부분 고정되어 있다.

 

[Request 2. Header]

 

 

위의 그림에 제시된 Header 예시는 매우 간단한 HTTP Request에 대한 것이기 때문에 밑에 설명하는 요소들이 모두 보이지 않는다. Header에서 백엔드 엔지니어로서 알고 있어야 하는 필수 요소들만 다루겠다.

 

① Host: Request의 목적지인 host의 URL 주소이다.

② User-Agent: Request를 보내는 클라이언트에 대한 정보이다.

③ Accept: 클라이언트가 Request를 보냈으며 서버 측으로부터 Response를 받아야 한다. Response를 받을 수 있는 date type를 서버한테 미리 알려주는 것이다. API는 JSON 데이터 타입으로 Response를 가장 많이 하기 때문에 대부분의 경우 “application/json”으로 request를 보낸다. 위의 경우 “*/*”은 모든 데이터 타입을 아우른다는 의미이다.

④ Connection: 클라이언트와 서버의 네트워크 연결 상태를 어떻게 유지할 것인지 지정해준다. 위와 같이 “Connection: keep-alive”의 경우 앞으로도 계속해서 HTTP 요청을 보낼 예정이니 네트워크 연결을 유지하라는 명령이다.

⑤ Content-Type: Accept의 반대되는 내용이다. 클라이언트가 서버로 보내는 데이터 타입이 무엇인지 알려준다. Accept와 마찬가지로 대부분의 경우 JSON 타입의 Body를 보낼 것이기 때문에 “application/json”으로 지정한다.

 

[Request 3. Body]

위의 예시에서는 간단한 GET 요청을 보내고 있기 때문에 Body가 없다. 나중에 서버에 저장하거나 보내고 싶은 데이터가 생기면 그때 HTTP Request에 추가해서 보내면 된다. 이는 다음 포스트에 다룰 예정이다.

 

[HTTP Response (응답)]

HTTP Response 도 총 3가지의 구성요소로 나눠진다.

 

① Status Line

② Header

③ Body

 

Response는 Request와 비슷한 구조로 형성되어 있다.

 

[Response 1. Status Line]

Request의 Start Line과 비슷하게 Status Line도 “HTTP version”, “Status Code”, “Status Text”로 구성되어 있다.

 

 

① “HTTP Version” = “HTTP/1.1”은 Request에서 다뤘던 버전 정보와 동일하다.

② Status Code는 HTTP Request 상태를 미리 저장된 숫자로 클라이언트한테 보내주는 것이다. 클라이언트가 웹에서 직접 보는 부분이기보다는 HTTP Response가 서버에서 이렇게 처리됐어요~라고 클라이언트 서버로 넘겨주는 것이다.

③ Status Text는 Status Code를 보완해주는 정보를 담고 있다. 자주 사용되는 Status Code와 Status Text는 다음과 같다.

1. 200 OK: HTTP Request가 성공적으로 잘 처리되었을 때를 의미한다. 가장 보고 싶은 Status Code 이기도 하다.
2. 301 Moved Permanently: HTTP Request의 목적지인 서버의 API 엔드포인트 URL 주소가 바뀌었다는 것이다. 대부분의 경우 “Location” 헤더를 포함해서 새로운 주소를 알려주고 그 위치로 다시 요청을 보내는 redirection 프로세스가 진행된다.

 

 

1. 400 Bad Request: HTTP Request가 잘못된 경우이다. 주로 Request에 포함된 input 값들이 잘못되었을 때 사용된다.
2. 404 Not Found: 존재하지 않는 URI에 Request를 보냈을 때 나온다. URI의 경우 “/ping”과 같이 엔드포인트의 고유주소를 의미한다.
3. 500 Internal Server Error: 내부 서버 오류가 발생했다는 것이다. 서버 쪽 문제로 백엔드 엔지니어가 해결해야한다.

 

[Response 2. Header & 3. Body]

Request와 유사하므로 생략한다.

 

[API 엔드포인트 아키텍처]

제목 그대로 API의 엔드포인트 구조를 구현하는 방식이다. 엔드포인트를 설계할 때 사용되는 대표적인 패턴으로는 REST 방식과 GraphQL이 있다.

 

REST → 대부분의 API 시스템

GraphQL → 페이스북 API 시스템 (현재 나의 관심사가 아니므로 다루지 않음)

 

[RESTful HTTP API]

REST = Representational State Transfer

RESTful API의 경우 API에서 전송하는 resource를 URI로 표현하고, 해당 리소스에 행하고자 하는 의도를 HTTP 메서드 (GET, POST, OPTIONS, etc.)로 정의하는 방식이다.

 

 

예를 들어 어떠한 고유의 기능을 수행하는 엔드포인트의 고유 주소를 “/ping”이라고 API 측에서 미리 프로그래밍을 해놓았다. 이런 엔드포인트에 HTTP Request를 RESTful 방식으로 보내면 다음과 같다.

 

 

새로운 사용자를 생성하는 엔드포인트 “/users”에 RESTful 형식의 HTTP Request를 보낸다면 다음과 같을 것이다.

 

다음 포스트에서는 좀 더 다양한 API 엔드포인트 기능들을 구현해 볼 것이다.