HTTP(HyperText Transfer Protocol)
TEXT, IMAGE, FILE, HTML, JSON 등 다양한 형태의 데이터가 HTTP를 통해 전송된다.
HTTP에도 버전이 존재하며 그중 대부분 HTTP/1.1 (TCP)을 사용한다. 현대에는 HTTP/2, HTTP/3 (UDP)의 사용량이 급속도로 증가하는 추세이다.
HTTP 동작 순서
HTTP는 클라이언트와 서버 사이에 이루어지는 요청/응답(request/response) 프로토콜이다. 예를 들면, 클라이언트인 웹 브라우저가 HTTP를 통하여 서버로부터 웹페이지(HTML)나 그림 정보를 요청하면, 서버는 이 요청에 응답하여 필요한 정보를 해당 사용자에게 전달하게 된다.
HTTP 특징
1️⃣ 클라이언트와 서버 구조
클라이언트는 UI(User Interface)에 중점을 두도록 만들고 서버에서 데이터, 비지니스 로직을 담당하도록 했다.
2️⃣ 무상태(Stateless)
서버는 클라이언트의 상태를 보존하지 않는다. 따라서 Scale Out 수평 확장성이 높아 갑자기 요청량이 증가하여도 서버를 증설하기 쉽다. 다만, 클라이언트가 데이터를 추가적으로 전송해야하며 무상태로 설계할 수 없는 로그인의 경우 쿠키, 세션, 토큰 등을 이용해야하는 한계점이 존재한다.
3️⃣ 비연결 (Connectionless)
HTTP는 연결을 유지하지 않는 모델이다. 따라서 서버의 자원을 효율적으로 사용할 수 있다. 그러나 요청이 추가적으로 오게되면 연결(3 way handshake)을 새로 해야하므로 요청에 대한 응답 시간이 증가한다. 따라서 웹 사이트의 정적 자원을 모두 다시 다운로드 해야한다. (해당 문제는 임시 저장하는 캐시, 브라우저 캐싱 등으로 해결 가능해진다.)
HTTP Message 구조
HTTP 메시지는 요청(Request)과 응답(Response) 두 가지로 나뉜다.
✅ HTTP 요청 메시지 (Request Message)
POST /event HTTP/1.1
Host: examplecoding.kr
Content-Type: application/json
{ "id": "examplecoding" }| 구성 요소 | 설명 | 예시 |
|---|---|---|
| Start Line | 메서드, 요청 경로, HTTP 버전 포함 | GET /search?keyword=example HTTP/1.1 |
| Header | 요청의 추가정보 (서버 정보, 데이터 형식 등) | Host: examplecoding.kr |
| Empty Line | 헤더와 바디 구분 (필수값) | 공백 한 줄 |
| Message Body | 실제 전송할 데이터 (JSON, HTML 등) | { "id": "examplecoding" } |
✅ HTTP 응답 메시지 (Response Message)
HTTP/1.1 200 OK
Content-Type: application/json
{ "success": true }| 구성 요소 | 설명 | 예시 |
|---|---|---|
| Start Line | HTTP 버전, 상태 코드, 상태 메시지 | HTTP/1.1 200 OK |
| Header | 응답의 추가 정보 | Content-Type: application/json |
| Empty Line | 헤더와 바디 구분 (필수값) | 공백 한 줄 |
| Message Body | 응답 데이터 (JSON, HTML 등) | { "success": true } |
HTTP Method
HTTP 메서드 간단 정리
| 메서드 | 역할 | 특징 |
|---|---|---|
| POST | 데이터 생성 | 주로 HTML 폼 제출(회원가입, 게시글 작성) , 서버에서 데이터를 받아 새 리소스를 생성 |
| GET | 데이터 조회 | - 데이터를 요청 (주로 읽기)- 데이터는 URL 내 Query로 전달 (메시지 본문 없음) - 예: /members?name=kim |
| PUT | 데이터 전체 수정 | - 기존 데이터 전체를 교체- 데이터 없으면 새로 생성 |
| PATCH | 데이터 일부 수정 | - 기존 데이터의 특정 필드만 수정 |
| DELETE | 데이터 삭제 | - 리소스를 서버에서 제거 |
기타 메서드 HEAD, OPTIONS, CONNECT, TRACE 간단 정리
| 메서드 | 설명 | 주요 용도 |
|---|---|---|
| HEAD | GET 요청과 유사하지만 본문 없이 헤더만 반환 |
리소스 존재 확인, 메타데이터 조회 |
| OPTIONS | 서버에서 지원하는 HTTP 메서드 조회 | API 엔드포인트 확인, CORS 처리 |
| CONNECT | 클라이언트와 서버 간의 암호화된 터널 생성 | HTTPS 프록시 설정 |
| TRACE | 요청 경로 추적 및 반사 | 네트워크 디버깅 (보안상 거의 비활성화됨) |
HTTP Method는 안전성(Safe), 멱등성(Idempotent), 캐시가능성(Cacheable) 속성을 가지고 있다.
✅ 안전성 (safe)
안전성이란 메서드가 호출될 때 서버의 데이터 상태를 변화시키지 않는 것을 의미한다. 즉, 읽기 전용(read-only)의 작업만 수행하여 데이터 변경이나 삭제 같은 작업이 없다는 것이다.
✅ 멱등성(Idempotent)
멱등성이란 한 번 호출하든 여러 번 호출하든, 결과가 항상 같아야 함을 의미한다. 멱등성이 보장되면, 네트워크 장애나 요청 실패가 발생할 경우 안전하게 재시도할 수 있다.
⚠️ 주의: 멱등성 오해
서버가 관리하는 데이터가 외부 요인에 의해 변경된 것은 멱등성 판단과 무관하다.
중요한 것은 서버의 같은 상태에서 같은 요청을 반복했을 때 결과가 항상 같아야 한다는 점이다.
✅ 캐시 가능성(Cacheable)
캐시 가능성은 특정 요청의 응답을 저장(캐싱)하여, 같은 요청이 들어오면 다시 서버에 요청하지 않고 저장된 결과를 제공할 수 있는지 여부를 의미한다. 캐싱을 사용하면 서버와 클라이언트 간의 불필요한 통신을 줄일 수 있다.
💡 캐시란?
클라이언트가 서버에 한 번 요청했던 데이터를 웹 브라우저나 중간 서버(Proxy)가 임시로 저장해두고, 동일한 요청 시 서버에 다시 요청하지 않고 저장된 데이터를 즉시 제공해주는 기술이다.
HTTP Status Code
1xx (정보)
- 요청을 받았고, 처리 중
- 거의 사용되지 않음
2xx (성공)
- 요청 성공
| 코드 | 설명 |
|---|---|
| 200 OK | 요청 성공 |
| 201 Created | 리소스 생성 성공 |
| 202 Accepted | 요청 수신 완료, 처리는 진행 중 (배치처리 등) |
| 204 No Content | 성공했지만 응답 본문 없음 (저장, 작성 버튼 클릭 시) |
3xx (리다이렉션)
- 요청을 완료하려면 추가 작업 필요, 클라이언트를 다른 곳으로 안내
- 3xx 응답 + Location HTTP Header가 있으면 Location 위치로 리다이렉트한다.
| 코드 | 설명 | 특징 |
|---|---|---|
| 301 Moved Permanently | 영구적 이동 | 메서드가 GET으로 변경 가능 |
| 308 Permanent Redirect | 영구적 이동 | 메서드 및 본문 유지 |
| 302 Found | 임시적 이동 | 메서드가 GET으로 변경될 수 있음 |
| 303 See Other | 임시적 이동 | 메서드가 무조건 GET으로 변경 |
| 307 Temporary Redirect | 임시적 이동 | 메서드 및 본문 유지 |
| 304 Not Modified | 캐시된 데이터를 사용 | 본문 포함 불가 |
일시 리다이렉션 : URI가 일시적으로 변경된 경우
- PRG 패턴: POST → Redirect → GET
(게시글 작성 후 리다이렉트 시 중복 요청 방지 목적)
4xx (클라이언트 에러)
- 클라이언트 요청이 잘못됨 (재시도 불필요)
| 코드 | 설명 |
|---|---|
| 400 Bad Request | 요청 문법 오류 |
| 401 Unauthorized | 인증(Authentication) 필요 |
| 403 Forbidden | 인가(Authorization) 거부 |
| 404 Not Found | 리소스 존재하지 않음 |
5xx (서버 에러)
- 서버 오류로 요청 처리 실패 (재시도 가능)
| 코드 | 설명 |
|---|---|
| 500 Internal Server Error | 일반적인 서버 오류 |
| 503 Service Unavailable | 서비스 이용 불가능 (서버 과부하 등) |
HTTP Header
클라이언트와 서버가 요청 또는 응답으로 부가적인 정보(Message Body 내용, 크기, 인증, 브라우저 정보, 서버 정보 등)를 전송할 수 있도록 만들어 준다. 즉, HTTP 메시지의 메타데이터(metadata) 역할을 합니다.
헤더는 요청(Request) 또는 응답(Response)의 본문을 설명하거나, 클라이언트와 서버가 통신할 때의 조건, 브라우저의 특성, 인증 정보, 쿠키, 콘텐츠 타입 등을 전달합니다.
헤더의 종류
| 유형 | 설명 | 예시 |
|---|---|---|
| 일반 헤더(General Header) | 요청과 응답 양쪽에 모두 사용될 수 있는 일반적인 정보 제공 | Date, Connection, Cache-Control |
| 요청 헤더(Request Header) | 클라이언트가 서버에 요청할 때 추가 정보 제공 | Accept, Host, User-Agent, Authorization |
| 응답 헤더(Response Header) | 서버가 클라이언트에게 응답할 때 추가 정보 제공 | Server, Content-Type, Content-Length, Set-Cookie |
| 엔터티 헤더(Entity Header) | 메시지의 바디에 포함된 콘텐츠에 대한 정보 제공 | Content-Type, Content-Encoding, Content-Length, ETag |
HTTP Header 모음
✅ 표현 헤더 (Representation) : 데이터 형식 및 인코딩 정보 전달, 요청과 응답 모두 사용
| 헤더명 | 용도 | 예시 |
|---|---|---|
| Content-Type | 미디어 타입과 문자 인코딩 | text/html; charset=utf-8, application/json |
| Content-Encoding | 데이터 압축 방식 | gzip, identity (미압축) |
| Content-Language | 데이터 언어 표현 | ko, en |
| Content-Length | 데이터 길이(byte) | 3487 |
✅ 콘텐츠 협상 헤더 (Content Negotiation) : 클라이언트가 원하는 데이터 형식을 요청 시 사용, 우선순위 지정 가능 (Quality Values, q 값: 0~1)
| 헤더명 | 용도 | 예시 |
|---|---|---|
| Accept | 미디어 타입 | application/json, text/plain |
| Accept-Charset | 문자 인코딩 | utf-8, iso-8859-1;q=0.5 |
| Accept-Encoding | 압축 방식 | gzip, deflate |
| Accept-Language | 언어 | ko-KR,en-US;q=0.9,en;q=0.8 |
✅일반 정보 헤더 : 부가 정보 전달
| 헤더명 | 용도 |
|---|---|
| From | 클라이언트 이메일 (거의 미사용) |
| Referer | 이전 페이지 URL (유입 경로 분석) |
| User-Agent | 클라이언트(브라우저 등) 정보 |
| Server | 서버 소프트웨어 정보 (응답 시 사용) |
| Date | HTTP 메시지 생성 시간 |
✅ 특별 정보 헤더 : 특정 상황에서 사용
| 헤더명 | 용도 |
|---|---|
| Host | 요청 도메인 (필수) |
| Location | 리다이렉트 주소나 생성된 리소스 위치 |
| Allow | 허용 메소드 (405 오류 시 사용) |
| Retry-After | 재요청 가능한 시간 (503 오류 시) |
✅ 인증 헤더 : 인증 관련 정보 전달
| 헤더명 | 용도 |
|---|---|
| Authorization | 클라이언트 인증 정보 |
| WWW-Authenticate | 서버가 요구하는 인증 방식 (401 오류 시) |
✅쿠키 헤더 : 상태 유지를 위한 쿠키 전송
| 헤더명 | 용도 |
|---|---|
| Set-Cookie | 서버가 클라이언트로 쿠키 전송 |
| Cookie | 클라이언트가 서버에 쿠키 전송 |
| Secure | HTTPS에서만 쿠키 전송 |
| HttpOnly | JavaScript 접근 방지 (XSS 방어) |
| SameSite | 동일 도메인 내에서만 쿠키 전송 (CSRF 방어) |
✅캐시 관련 헤더 : 데이터 재사용을 통한 성능 개선
| 헤더명 | 용도 |
|---|---|
| Cache-Control | 캐시 제어 (max-age, no-cache, no-store) |
| If-Modified-Since | 캐시된 데이터의 마지막 수정 날짜 확인 |
| Last-Modified | 데이터 마지막 수정 날짜 |
| ETag | 데이터 식별자 (버전 관리 및 캐시 정확성 개선) |
Restful API
REST를 잘 준수하는 API로 HTTP 프로토콜을 사용하여 클라이언트와 서버 간의 통신을 통해 자원(Resource)을 관리한다. 자원은 고유한 URI로 식별되며, HTTP 메서드(GET, POST, PUT, DELETE 등)를 통해 다양한 작업을 수행하며 요청과 응답은 일반적으로 JSON 또는 XML 형식으로 이루어진다.
What is RESTful?
REST란 ?
REST (Representational State Transfer)는 웹 서비스 설계 아키텍처의 하나로, 자원(Resource)을 정의하고 이를 HTTP 프로토콜을 통해 상태를 주고 받는 방식이다. 자원(Resource)을 이름(Name)으로 구분하여 해당 자원의 상태(정보)를 주고받는 것을 의미한다. 즉, 클라이언트와 서버 간의 상호작용을 규정하며, 웹의 기본 원칙과 패턴을 따르는 서비스 설계 방법론이다.
☑️자원(Resource)
자원은 웹 상에서 식별할 수 있는 모든 것(ex. 사용자, 게시물, 댓글, 상품)
☑️ 표현(Representation)
자원의 표현은 자원이 전송될 때, 그 자원의 상태를 어떻게 표현하는지에 대한 것 (자원의 상태를 클라이언트와 서버 간에 교환하는 것이 핵심) 일반적으로 JSON이나 XML 형태로 전송
☑️무상태성
서버가 클라이언트의 상태를 저장하지 않으며, 각 요청은 독립적이라는 의미
클라이언트는 요청 시 필요한 모든 정보를 포함하여 서버에 보내야 하며, 서버는 요청을 처리하고 필요한 응답을 반환
☑️계층 구조
REST 아키텍처는 계층적인 구조를 지향함
클라이언트는 서버와의 직접적인 통신 외에도, 프록시나 게이트웨이 같은 중간 계층을 통과하여 서버와 상호작용할 수 있음.
https://restfulapi.net/resource-naming/
더 자세한 내용은 다음 내용을 참고하면 된다. 참고 자료를 정리한 내용은 다음과 같다.
- 리소스는 명사를 사용해야 한다.
- 단수가 아닌 복수 형태를 사용해야 한다.
- 만약, REST만으로 해결하기 어려운 경우라면 동사를 허용한다.
- 자원의 계층 관계를 슬래시(/)로 표현한다.
- 마지막 문자에는 슬래시(/)가 있으면 안된다.
- 언더바(_)가 아닌 하이픈(-)을 사용해야 한다.
- 소문자를 사용해야 한다.
- URI에 파일 확장자를 포함하면 안된다.
- CRUD 함수명은 사용하지 않고, HTTP Method를 활용해야 한다.
- 정렬, 필터링, 페이징은 신규 API를 만드는것이 아닌 Query Parameter를 사용해야 한다.
💬 내가 클라이언트의 입장이라면 좋아할만한 API path
- RESTful 표준 준수 (POST,GET, PATCH, DELETE)
- 자원 기반의 일관된 경로 (모든 경로 앞에 /api/를 붙이는 식으로)
- 경로에는 가능한 동작을 사용하지 않는 것
- 어순에 맞춰서 (ex 특정 사용자의 게시물 조회) →
GET /api/users{userId}/posts