# 정의 ### HTTP 프로토콜이란? > HTTP는 웹에서 리소스를 주고받기 위한 애플리케이션 OSI 7계층 프로토콜이다. 클라이언트(브라우저)가 요청(request)을 보내고, 서버가 응답(response)을 반환하는 방식으로 동작한다. ### 특징 - **클라이언트 - 서버 구조 & Statelessness (무상태성)** HTTP는 Stateless 방식으로, 즉 각각의 요청은 **독립적이고, 이전 요청의 상태를 기억하지 않는다.** - **전송계층과 관계** HTTP는 주로 TCP 위에서 실행되며, 보안을 위해 TLS를 적용한 HTTPS 형태로 사용된다 (HTTP 80 / HTTPS 443).

📌 ## Stateless vs Stateful ### Stateless (무상태) 정의 : 서버가 클라이언트의 이전 요청 상태를 기억하지 않는다. - 각 요청이 독립적으로 이루어지며, 요청에 필요한 모든 정보가 매번 담겨야 한다. - 서버는 클라이언트별 세션 저장소가 필요 없다 → **확장성, 로드밸런싱에 유리하다.** - 실패/재시도 설계가 단순하다. - HTTP, UDP가 기본 구조이며, REST API 설계의 기반이다. ### Stateful (상태 유지) 정의 : 서버가 클라이언트의 상태를 보존하고, 이후 요청을 그 상태에 의존하여 처리한다. 특징으로는: - 연결/세션 정보(로그인 상태, 진행 중인 트랜잭션 등)를 서버가 보관한다. - 특정 서버와의 지속적인 연결이 필요함 → 수평적 확장 시 세션 동기화 필요. - 더 풍부한 기능(멀티 스텝 트랜잭션, 채팅 연결 유지)이 가능하지만 관리 부담이 증가한다. - 전통적인 TCP 소켓 통신이나, HTTP 서버 세션 저장소 기반 로그인에서 사용한다. **정리하면:** - **Stateless**: 매 요청 시마다 필요한 정보를 담아서 전송한다. (예: JWT 토큰) - REST API, HTTP 통신에서 사용 - **Stateful**: 한번 세션을 연결하면, 이 세션이 연결된 상태를 유지한다. (예: 일반적인 세션) - 실시간 연결, 인증 세션 등에서 사용된다.

## Request & Response ### Request (요청) - 클라이언트가 서버에게 특정 동작을 수행해달라고 전달하는 메시지 - 구조 : 요청 라인 + 헤더 + 바디 - 예: `/login` 페이지를 GET해줘, 이 JSON 데이터를 POST해줘 **Request Line 구조:** `<메서드>` `` `` (ex : `GET /index.html HTTP/1.1`) ## Response (응답) 서버가 클라이언트 요청을 처리한 뒤 결과를 알려주는 메시지 - 구조: 상태 라인(Status Line) + 헤더 + 바디 - Response Line 구조: `` `` `` ### 상태코드(Status Code)란? 상태코드는 서버가 클라이언트 요청을 어떻게 처리했는지 알려주는 숫자이다. 기본적으로 **3자리의 숫자 + 이유 구문(Reason Phrase)**으로 구성되어 있고 1xx ~ 5xx의 범위로 나뉘어져 있다. 클라이언트는 코드만 보고 요청이 성공했는지, 다시 시도해야 하는지, 인증이 필요한지 등을 알 수 있다. 자세한 건 해당 사이트 참고: [MDN HTTP Status](https://developer.mozilla.org/ko/docs/Web/HTTP/Reference/Status) ## REST API (REpresentational State Transfer)란? "HTTP를 최대한 웹 친화적이고, 일관성이 있는 자원 중심 방식으로 쓰자"라는 목적으로 만든 API이다. 정확하게는 두 컴퓨터 시스템이 인터넷을 통해서 정보를 안전하게 교환하기 위해서 사용하는 인터페이스다. ### REST 원칙 1. **자원(Resource) 지향** - 모든 것은 자원으로 표현된다. → URI로 식별한다. - 예: `/user/123` (ID가 123인 유저) 2. **표현(Representation)** - 자원은 JSON, XML, HTML 등으로 표현 가능하다. (현대에서는 JSON이 사실상 표준) 3. **무상태성 (Statelessness)** 4. **일관된 인터페이스** - 같은 규칙, 같은 메서드 → 학습 및 사용이 용이하다. 5. **캐시 가능** - 응답에 캐시 여부 명시 ### HTTP 메서드 클라이언트가 서버에게 "이 리소스에 대해 어떤 동작을 해달라"고 지정하는 방식이다. #### 1. 주요 메서드 (REST에서 필수) | 메서드 | 의미 | 특징 | 예시 | | --- | --- | --- | --- | | GET | 자원 조회 | 안전(Safe), 멱등(Idempotent), 캐시 가능 | `GET /users/42` → 유저 정보 조회 | | POST | 자원 생성 / 처리 요청 | 멱등 아님, 본문(body) 전송, 새 리소스 생성 | `POST /users` → 새 유저 등록 | | PUT | 자원 전체 생성/대체 | 멱등(Idempotent), 같은 요청 반복 시 동일 결과 | `PUT /users/42` → 유저 전체 정보 업데이트 | | PATCH | 자원 일부 수정 | 부분 변경, 멱등 보장 여부는 구현 따라 다름 | `PATCH /users/42` → 이메일만 수정 | | DELETE | 자원 삭제 | 멱등(Idempotent) | `DELETE /users/42` → 유저 삭제 | #### 2. 보조 메서드 | 메서드 | 의미 | 특징 | 예시 | | --- | --- | --- | --- | | HEAD | GET과 동일하되 body 없음 | 메타데이터 확인용 (캐시, Content-Length 등) | `HEAD /file.zip` | | OPTIONS | 서버/리소스가 지원하는 메서드 조회 | CORS Preflight 요청에 자주 사용됨 | `OPTIONS /api` | | TRACE | 요청이 서버까지 가는 경로 반환 | 디버깅용, 보안상 위험 → 일반적으론 차단 | `TRACE /` | | CONNECT | 프록시 터널링 요청 | 주로 HTTPS 연결용 | `CONNECT www.example.com:443` |