HTTP의 구조 및 핵심 요소

홍진우·2022년 3월 22일

Back-End

목록 보기

3/10

프론트엔드 시스템과 백엔드 API 시스템은 일반적으로 HTTP 프로토콜을 기반으로 통신한다. 따라서, 백엔드 API 시스템을 구현하는데 있어 HTTP 프로토콜을 이해하는 것은 필수이며, 이에 대해 정리해보고자 한다.

1) HTTP 핵심요소

HTTP 요청과 응답

HTTP는 기본적으로 요청(request)과 응답(response)의 구조로 되어 있음. HTTP를 기반으로 통신할 때 클라이언트가 먼저 HTTP 요청을 서버에 보내면 서버는 요청을 처리한 후 결과에 따른 HTTP 응답을 클라이언트에게 보냄으로써 하나의 HTTP 통신이 된다.

지난번에 구현한 백엔드 API 시스템의 엔드포인트 구현도 기본적으로 HTTP 요청을 인풋으로 받아서 HTTP 응답을 아웃풋으로 응답하는 구조였다.

# Flask의 route 데코레이터(decorator)를 사용하여 엔드포인트 등록
# 이후 나오는 ping 함수를 엔드포인트 함수로 등록하였으며, 고유주소는 "ping", HTTP 메소드는 GET으로 설정
@app.route("/ping", methods=['GET'])

# ping함수 정의. route 데코레이터를 통해서 엔드포인트로 등록된 함수이며, "pong"이라는 string을 리턴함
# Flask가 알아서, HTTP response로 변환하여 해당  HTTP 요청을 보낸 클라이언트에게 전송함
def ping():
    return "pong"

"ping" 엔드포인트의 경우에도 마찬가지로 HTTP 요청과 응답이 오고 가는 구조이며,

이 경우 HTTP 요청은 "/ping" 주소에 GET 요청을 보내는 것이고,
HTTP 응답은 200 OK 상태코드와 함께 "pong"이라는 텍스트를 보내는 것

보이지 않는 부분은 Flask가 자동으로 처리

stateless

HTTP 통신은 말그대로 상태라는 개념이 존재하지 않음
즉, HTTP 프로토콜에서는 동일한 클라이언트와 서버가 주고받은 HTTP 통신들이라도 서로 연결되어 있지 ㅇ낳고, 각각의 HTTP 통신은 독립적이며, 그전에 처리된 HTTP 통신에 대해서도 전혀 알지 못함

따라서, HTTP 통신들의 상태를 서버에 저장할 필요가 없으므로, 여러 다른 HTTP 통신간의 진행이나 연결상태의 처리나 저장을 구현 및 관리하지 않아도 되고, 각각의 HTTP 요청에 대해 독립적으로 응답만 보내주면 된다.
추가로, 이러한 stateless란 특징 때문에 예를 들어 HTTP 요청을 처리하기 위해서는 해당 사용자가 로기인이 되어 있어야 한다고 할 때, 새로 보내는 HTTP 통신에서는 해당 사용자가 그 전 HTTP 통신에서 로그인했다는 사실을 알지 못ㅎ나다. 따라서, 사용자의 로그인 사실 여부를 포함해서 HTTP 요청을 보내기 위해 클라이언트 단에서 사용자가의 로그인 사실 여부를 쿠키(cookie)나 세션(session) 등을 통해 HTTP 요청을 처리할때 필요한 진행 과정이나 데이터를 저장한다.

2) HTTP 구조

HTTP 요청 구조

HTTP 요청 메시지의 구조는 크게 다음의 3부분으로 구성되어 있다.

Start Line

Headers

Body

Start line
말 그대로 HTTP 요청의 시작줄. 예를 들어 "search" 엔드포인트에 GET HTTP 요청을 보낸다면 해당 HTTP 요청의 start line은 다음과 같다.
```
GET /search HTTP/1.1
```
start line은 다음의 세부분으로 구성되어 있다.
- HTTP 메소드
  해당 HTTP 요청이 의도하는 action을 정의하는 부분
  서버로부터 어떠한 데이터를 받고자 한다면, GET
  서버에 새로운 데이터를 저장하고자 한다면 POST 의 요청을 보내는 식
- Request target
  해당 HTTP 요청이 전송되는 목표주소
- HTTP version
  말그래도 해당 요청의 HTTP 버전
Headers
헤더 정보는 HTTP 요청 그 자체에 대한 정보를 담고 있다. 예를 들어 HTTP 요청 메세지의 전체 크기(Content-Length)가 있다.
파이썬의 dictionary 처럼 key와 value로 이루어져 있으며, 예를 들어 google.com에 보내는 HTTP 요청의 HOST 헤더의 경우 다음과 같이
```
HOST : google.com
```
으로 Key:Value의 쌍으로 표현된다.
자주 사용되는 헤더는 다음이 있다.
- Host
  요청이 전송되는 target의 호스트의 URL주소를 알려줌.
- User-Agent
  요청을 보내는 클라이언트에 대한 정보
- Accept
  해당 요청이 받을 수 있는 응답 body 데이터 타입을 알려주는 헤더
- Connection
  해당 요청이 끝난 후에 클라이언트와 서버가 계속해서 네트워크 연결을 유지할 것인지, 끊을 것인지에 대해 알려주는 헤더
- Content Type
  HTTP 요청이 보내는 메세지 bodyy 타입을 알려주는 헤더
- Content-Length
  HTTP 요청이 보내는 메세지 body의 총 사이즈를 알려주는 헤더
Body
HTTP 요청이 전송하는 데이터를 담고 있으며, 전송하는 데이터가 없다면 비어 있음

추가로 Flask, Django와 같은 웹 프레임워크들이 모두 알아서 처리해주기 때문에, 우리가 모든 HTTP 요청과 응답 메세지의 모든 부분을 직접 구현할 필요가 없다. 일반적으로 개발자가 직접 지정해야 하는 부분은 HTTP 메소드와 status code, 몇개의 헤더 정보, body 부분이다.

HTTP 응답 구조

Status Line

Headers

Body

Status Line
HTTP 응답 메시지의 상태를 간략하게 요약하여 알려주는 부분
Headers
Body

헤더와 바디는 HTTP 요청의 헤더 부분과 동일

3) 자주 사용되는 HTTP 메소드와 Status Code

자주 사용되는 HTTP 메소드

GET

이름 그대로 어떠한 데이터를 서버로부터 요청할 때 주로 사용 되는 메소드. 데이터의 생성이나 수정, 삭제 등의 변경사항 없이 단순히 데이터를 받아오는 요청이며, 해당 HTTP 요청의 body가 비어있는 경우가 많다.

Post

GET과 다르게 데이터를 생성, 수정 및 삭제 요청을 할 때 주로 사용된다.

OPTIONS

특정 엔드포인트에서 허용하는 메소드들이 무엇이 있는지 알고자 하는 요청에서 사용되는 HTTP 메소드
엔드포인트는 허용하는 HTTP 메소드가 지정되도록 되어 있으며, 허용하지 않는 HTTP 메소드의 요청이 들어오면 405 Method Not Allowed 응답을 보냄.

예를 들어 이전에 구현한 "ping" 엔드포인트의 경우 GET 엔드포인트만 요청 받도록 구현되어 있다.

PUT

Post 메소드와 중복되는 의미로, 데이터를 새로 생성할 때 사용. 굳이 사용하지 않고 다 POST로 통일해서 사용하자.

DELETE

삭제할때 사용되며, 위와 동일

자주 사용되는 HTTP Status Code와 Text

200 OK

HTTP 요청이 문제없이 성공적으로 잘 처리되었을 때

301 Moved Permanently

HTTP 요청을 보낸 엔드포인트의 URL 주소가 바뀌었다는 것을 나타냄

400 Bad Request

이름 그대로 HTTP 요청이 잘못된 요청일 때. 주로 요청에 포함된 인풋 값들이 잘못된 값들일 때

401 Unauthorized

HTTP 요청을 처리하기 위해서는 해당 요청을 보내는 주체의 신분 확인이 요구되나 확인할 수 없었을때.
주로 해당 HTTP 요청을 보내는 사용자가 로그인이 필요한 경우

403 Forbidden

HTTP 요청을 보내는 주체가 해당 요청에 대한 권한이 없을 때

404 Not Found

HTTP 요청을 보내고자하는 URL이 존재하지 않을 때 보내는 응답 코드

500 Internal Server Error

이름 그대로, 내부 서버 오류가 발생했다는 것을 알려주는 응답 코드. 서버의 오류

API 엔드포인트 아키텍처 패턴

RESTful HTTP API

API에서 전송하는 resource를 URL로 표현하고 해당 리소스에 행하고자 하는 의도를 HTTP 메소드를 정의하는 방식
각 엔드포인트는 처리하는 리소스를 표현하는 고유의 URL 주소를 가지고 있으며, 해당 리소스에 행할 수 있는 행위를 표현하는 HTTP 메소드를 처리할 수 있게 된다.

RESTful HTTP API의 가장 큰 장점은 자기설명력이 높다는 점. 즉 엔드포인트의 구조만 보더라도 해당 엔드포인트가 제공하는 리소스와 기능을 파악할 수 있다.

홍진우

Yonsei Univ. Sports Industry studies/ Computer Science / Applied Statistics

이전 포스트

API 개발

다음 포스트