HTTP를 파보자

우노·2024년 6월 23일

CS 프로토콜

CS

목록 보기

1/5

HTTP (Hypertext Transfer Protocol)

Hyper Text Transfer Protocol (텍스트를 뛰어넘는 걸 통신하는 규약)
➕ Hyper Text: 한 문서에서 다른 문서로 즉시 접근할 수 있는 텍스트

🌐 W3에서 동작하는 Client-Server의 요청-응답 구조 통신 프로토콜

대표적으로 Client(웹 브라우저)-Server(웹 서버)의 통신에서 활용됩니다.
그리고 현재 웹에서는 HTTP/1.1, HTTP/2, HTTP/3을 활용하고 있습니다.

URL에서 http: https: 로 프로토콜을 확인할 수 있습니다!
➕ 참고로 rmi: 나 sftp: 등의 프로토콜도 가능합니다.

특징

평문(ASCII) 메시지로 통신 - 가독성 있는 일반 텍스트

HTML, TEXT, 이미지, 음성, 영상, 파일, JSON, XML 등을 주고받음

Stateless Protocol + Connectionless - 각 요청을 개별적으로 처리

80번 포트 활용

TCP/IP 기반 동작 + HTTP Pipelining(keep-alive) 지원 (1.1 기준)

Head-of-line blocking 문제 발생 가능 (1.1 기준, 2에서 다중화로 해결)

기본 메시지 형식

start-line / header / empty line / message body

METHOD /URL PROTOCOL
Host: www.google.com
(CRLF)
message body

요청

start-line | [요청 메소드][URL][프로토콜]
header | key:value 형태로 웹사이트 도메인의 호스트, 언어, 사용자의 브라우저 등을 전달
empty line | 공백 라인 (CRLF, 필수)
message body | HTML, 이미지, 영상, JSON 등 byte로 표현할 수 있는 모든 데이터

GET /abc HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0
Accept-Language: ko-KR
Authorization: Bearer UExBMDFUMDRQV1MwMnzpdvtYYNWMSJ7CL8h0zM6q6a9ntw

응답

start-line | [프로토콜][상태 코드][상태 문구]
header | key:value 형태로 서버 애플리케이션 정보 등 전달
empty line | 공백 라인 (CRLF, 필수)
message body | HTML, 이미지, 영상, JSON 등 byte로 표현할 수 있는 모든 데이터

HTTP/1.1 200 OK
Date: Sat, 09 Oct 2023 14:28:02 GMT
Server: Apache
Content-Type: text/html

<html>
...
</html>

요청 HTTP Method

mdn docs 요약 표입니다!
여기서 안전함은 서버의 상태를 바꾸지 않음을 의미합니다.

GET: 특정한 리소스를 가져오도록 요청
- 데이터를 가져올 때만 사용해야 함
- body 등에 데이터를 담는 것이 금지는 아니지만 담지 않는 것을 권고
HEAD: 특정 리소스를 GET 메서드로 요청했을 때 돌아올 헤더 요청
POST: 서버로 데이터 전송하여 처리 (새로운 리소스 생성 등)
⚡멱등성 X - 요청마다 다른 데이터 반환 가능 (성공/실패/etc)
PUT: 서버로 데이터를 전송하여 처리 (새로운 리소스를 생성하, 대상 리소스를 데이터로 대체 등)
⚡멱등성 O - 요청마다 같은 데이터 반환
DELETE: 저장한 리소스 삭제
CONNECT: 요청한 리소스에 대해 양방향 연결 시작
ex. HTTPS 사용하는 웹사이트 접속에 사용 가능
OPTIONS: 주어진 URL 또는 서버에 대해 허용된 통신 옵션 요청
TRACE: 웹서버로 가는 네트워크 경로를 확인
PATCH: 리소스의 부분적인 수정

응답 상태 코드 분류

100(정보) | 200(성공) | 300(리다이렉션) | 400(클라이언트 오류) | 500(서버 오류)

REST; Representational State Transfer

W3에서 HTTP를 사용하는 소프트웨어 설계 철학 (JSON으로 데이터를 실어나르는 방식)
REST 이전에는 엄격히 지켜야하는 XML 기반의 프로토콜인 SOAP(Simple Object Access Protocol)이 있었습니다.

하지만 다양한 이유로 SOAP이 비효율적이라고 느껴지자..
→ REST라는 철학이 등장하고 이걸 지켜서 설계하면 RESTful하다고 칭합니다!
⇒ 결국 HTTP를 효율적으로 제대로 활용하기 위한 유연한 규칙입니다.

이름에서부터 알 수 있듯이 REST는 다음과 같습니다.

🌐 자원을 이름으로 구분하여 해당 자원의 상태(정보)를 주고 받는 모든 것

자원(Resource) : 자원을 명시하는 URI (unique end-point)
행위(Verb): HTTP Method
표현(Representations) : JSON, XML, Text 등 다양한 형식으로 자원 표현

원칙

클라이언트-서버 아키텍처
아키텍처 단순화 + 작은 단위로 분리
기술, 플랫폼, 프로그래밍 언어 등과 관련하여 서로 독립적
계층화
서버에 클라이언트 요청을 위한 여러 중간 서버가 있을 수 있지만 클라이언트는 알 수 없음
인터페이스 일관성
일관적인 인터페이스로 분리
무상태(Stateless)
API는 이전 요청과 독립적으로 모든 요청을 처리 (클라이언트의 context 고려하지 않음) → 덕분에 확장이 쉬워짐
캐싱 처리 가능
모든 API 응답은 캐싱할 수 있어야함 (중간 서버 활용 가능)
온디맨드 코드
필요한 경우에 서버가 클라이언트가 실행시킬 수 있는 로직을 전송하여 기능 확장
ex. API 응답에 코드 스니펫 포함

특징

함수가 아닌 URI 노출로 통신

XML, JSON, 일반 텍스트, HTML 등을 지원하지만 보편적으로 JSON 송수신

POST/GET/PUT/DELETE - CRUD (Create/Read/Update/Delete)

엄격한 규칙이 아니므로 REST 정의 내에서 자유롭게 활용 가능

ex. CRUD HTTP Method 활용은 거의 동일한데 나머지는 회사마다 다를 수도 있음

URI와 응답 데이터를 잘 구성하기 위한 Self-descriptive 규칙을 어떻게 구성하느냐도 활용 방법 중 하나

Self-descriptive
REST API만 보고도 이해할 수 있게 하는 자체 표현 구조

자원 - URI
- 동사보다 명사로, 소문자로 표현
- Document(객체)는 단수 / Collection(집합)은 복수
- Store(모음)은 복수
- 슬래시 구분자 / 로 계층 관계 표현
- URI 마지막에 슬래시 구분자 / 포함 X
- 하이픈 - 가독성 증가 + 언더바 _ 가독성 감소
행위 - HTTP Method
- URI에 HTTP method 또는 동사 포함 X

자료 출처
mdn web docs

우노

기록하는 감자

다음 포스트