HTTP의 구조 및 핵심 요소
프론트엔드 시스템과 백엔드 API 시스템은 일반적으로 HTTP 프로토콜을 기반으로 통신한다. 따라서, 백엔드 API 시스템을 구현하는데 있어 HTTP 프로토콜을 이해하는 것은 필수이며, 이에 대해 정리해보고자 한다.
목차
- HTTP 핵심요소
- HTTP 구조
- 자주 사용되는 HTTP 메소드와 Status Code
HTTP
Hyper Text Transfer Protocol의 약자로, 웹상에서 서로 다른 서버간의 하이퍼텍스트 문서, 즉 HTML을 주고 받을수 있도록 만들어진 프로토콜, 통신 규약(이러한 방식, 형식으로 통신하자고 규정해 놓은 통신 형식, 구조")
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은 다음과 같다.
start line은 다음의 세부분으로 구성되어 있다.GET /search HTTP/1.1
- HTTP 메소드
해당 HTTP 요청이 의도하는 action을 정의하는 부분
서버로부터 어떠한 데이터를 받고자 한다면, GET
서버에 새로운 데이터를 저장하고자 한다면 POST 의 요청을 보내는 식 - Request target
해당 HTTP 요청이 전송되는 목표주소 - HTTP version
말그래도 해당 요청의 HTTP 버전
- HTTP 메소드
- Headers
헤더 정보는 HTTP 요청 그 자체에 대한 정보를 담고 있다. 예를 들어 HTTP 요청 메세지의 전체 크기(Content-Length)가 있다.
파이썬의 dictionary 처럼 key와 value로 이루어져 있으며, 예를 들어 google.com에 보내는 HTTP 요청의 HOST 헤더의 경우 다음과 같이
으로 Key:Value의 쌍으로 표현된다.HOST : google.com
자주 사용되는 헤더는 다음이 있다.- Host
요청이 전송되는 target의 호스트의 URL주소를 알려줌. - User-Agent
요청을 보내는 클라이언트에 대한 정보 - Accept
해당 요청이 받을 수 있는 응답 body 데이터 타입을 알려주는 헤더 - Connection
해당 요청이 끝난 후에 클라이언트와 서버가 계속해서 네트워크 연결을 유지할 것인지, 끊을 것인지에 대해 알려주는 헤더 - Content Type
HTTP 요청이 보내는 메세지 bodyy 타입을 알려주는 헤더 - Content-Length
HTTP 요청이 보내는 메세지 body의 총 사이즈를 알려주는 헤더
- Host
- 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의 가장 큰 장점은 자기설명력이 높다는 점. 즉 엔드포인트의 구조만 보더라도 해당 엔드포인트가 제공하는 리소스와 기능을 파악할 수 있다.
Author And Source
이 문제에 관하여(HTTP의 구조 및 핵심 요소), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다 https://velog.io/@eclat12450/HTTP의-구조-및-핵심-요소저자 귀속: 원작자 정보가 원작자 URL에 포함되어 있으며 저작권은 원작자 소유입니다.
우수한 개발자 콘텐츠 발견에 전념 (Collection and Share based on the CC Protocol.)