📕 목차
- HTTP(HyperText Transfer Protocol)
- HTTP 특징
- HTTP 동작 순서
- HTTP Message 구조
- HTTP Method
- HTTP 상태 코드
- HTTP API 설계
- HTTP Header
- Restful API
1. HTTP(HyperText Transfer Protocol)
- 웹에서 정보를 주고받는 방식에 대한 규칙을 정의하는 프로토콜
- 웹 브라우저와 서버 간의 데이터 전송을 위한 프로토콜이다.
- HTTP는 클라이언트-서버 구조를 기반으로 하며, 클라이언트(예: 웹 브라우저)는 서버에 요청을 보내고 서버는 이에 대한 응답을 반환한다.
2. HTTP 특징
- 클라이언트-서버 구조
- HTTP는 클라이언트(주로 브라우저)와 서버 간의 통신을 관리한다.
- 라이언트는 요청을 보내고, 서버는 그 요청을 처리한 후 응답을 보낸다.
- 무상태(Stateless)
- HTTP는 각 요청을 독립적으로 처리하며, 서버는 이전 요청에 대한 정보를 기억하지 않는다.
- 즉, 한 요청이 끝나면 상태가 유지되지 않는다.
- 비연결(Connectionless)
- HTTP는 요청과 응답 후 연결을 종료하며, 연결을 유지하지 않는다.
- 그러나 HTTP/1.1에서는 지속 연결(Persistent Connection)을 지원하여 여러 요청을 하나의 연결로 처리할 수 있다.
- 텍스트 기반
- HTTP는 기본적으로 텍스트 기반의 프로토콜로, 요청과 응답 메시지가 사람이 읽을 수 있는 형태로 전송된다.
3. HTTP 동작 순서
- 클라이언트는 서버에 요청을 보내고 응답을 기다린다.
- 서버는 요청을 처리하고 결과를 응답한다.
4. HTTP Message 구조
HTTP 요청 메시지(Request Message)
POST /submit-form HTTP/1.1 // 요청 라인(Request Line)
Host: www.example.com // 헤더(Header)
Content-Type: application/x-www-form-urlencoded
Content-Length: 23
// 공백 한줄
name=JohnDoe&email=john@example.com // 본문(Body)더보기
더보기
요청 라인(Request Line)
- HTTP 메소드(Method)
- 클라이언트가 서버에 요청할 작업을 정의한다.
- ex. GET, POST, PUT, DELETE 등
- 경로(Path)
- 서버에서 요청할 리소스의 경로를 정의한다.
- ex. /index.html, /api/user 등
- HTTP 버전(HTTP Version)
- 사용되는 HTTP 프로토콜의 버전을 정의한다.
- ex. HTTP/1.1, HTTP/2 등
헤더(Header)
- 요청에 대한 추가 정보를 제공한다.
- 클라이언트가 사용하는 브라우저나 서버에서 기대하는 콘텐츠 타입 등을 정의한다.
공백 한 줄(Empty Line)
- 필수 값
본문(Body)
- 서버로 보낼 실제 데이터를 포함한다.
- GET 요청에서는 본문이 없으며, POST나 PUT 요청에서는 본문에 데이터가 포함된다.
HTTP 응답 메시지(Response Message)
HTTP/1.1 200 OK // 상태 라인(Status Line)
Content-Type: text/html; charset=UTF-8 // 헤더(Header)
Content-Length: 3050
Date: Sat, 03 May 2025 12:00:00 GMT
// 공백 한줄
<!DOCTYPE html> // 본문(Body)
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Welcome</title>
</head>
<body>
<h1>Welcome to my website!</h1>
</body>
</html>더보기
더보기
상태 라인(Status Line)
- HTTP 버전(HTTP Version): 서버가 사용하는 HTTP 프로토콜 버전을 정의한다.
- 상태 코드(Status Code): 요청 처리 결과를 나타내는 3자리 숫자 코드이다.
- 상태 텍스트(Status Text): 상태 코드에 대한 간단한 설명이다.
헤더(Header)
- 응답에 대한 추가 정보를 제공한다.
- 클라이언트가 응답을 어떻게 처리할지에 대한 지침이나 서버 정보 등이 포함된다.
공백 한 줄(Empty Line)
- 필수 값
본문(Body)
- 서버가 클라이언트에게 보내는 실제 데이터이다.
- 주로 요청한 HTML 문서, JSON 데이터, 이미지 파일 등이 포함된다.
5. HTTP Method
클라이언트 - 서버 사이에 이루어지는 요청, 응답 데이터를 전송하는 방식을 뜻한다.
HTTP Method 종류
- GET, POST, PUT, PATCH, DELETE
더보기
더보기
GET
GET /users?id=123 HTTP/1.1- 서버에서 데이터를 조회할 때 사용한다.
- 요청 시 서버에 아무런 변경을 일으키지 않는다. (= 읽기 전용)
- URL에 쿼리 파라미터를 붙여 요청 데이터를 전달한다.
- 브라우저의 주소창에 입력하거나 링크를 클릭할 때 자동으로 GET 요청이 발생한다.
- 본문(body)을 포함하지 않는다.
POST
POST /users HTTP/1.1
Content-Type: application/json
{
"name": "Alice",
"email": "alice@example.com"
}- 서버에 데이터를 제출하거나 새로운 리소스를 생성할 때 사용한다.
- 서버의 상태나 데이터에 변화를 일으킨다.
- 요청 데이터는 본문(body)에 담아서 전송한다.
- GET과 달리 요청 데이터가 URL에 보이지 않아 보안상 유리하다.
PUT
PUT /users/123 HTTP/1.1
Content-Type: application/json
{
"name": "Alice Updated",
"email": "alice_new@example.com"
}- 서버에 데이터를 보내어 전체 리소스를 덮어쓰기 방식으로 업데이트할 때 사용한다.
- 지정된 리소스가 없으면 새로 생성하기도 한다.
- 기존 데이터를 완전히 대체하기 때문에 전체 필드를 보내야 한다.
- 요청 본문에 업데이트할 데이터를 포함한다.
PATCH
PATCH /users/123 HTTP/1.1
Content-Type: application/json
{
"email": "alice_updated@example.com"
}- 서버의 리소스를 부분적으로 수정할 때 사용한다.
- PUT과 달리 전체를 보내지 않고, 바꾸려는 필드만 보내면 된다.
- 리소스의 일부분만 변경하므로 효율적이다.
DELETE
DELETE /users/123 HTTP/1.1- 서버에서 특정 리소스를 삭제할 때 사용한다.
- 삭제 요청 시 리소스를 제거하고, 일반적으로 204 No Content 또는 200 OK로 응답한다.
- 요청 본문은 필요하지 않은 경우가 많다
HTTP Method 속성
- 안전성 (Safe)
- 서버의 상태나 데이터에 영향을 주지 않는 요청을 안전하다고 한다.
- 데이터를 단순히 조회만 하고 변경하지 않는 메소드는 안전하다고 본다.
- 멱등성 (Idempotent)
- 같은 요청을 여러 번 반복해도 결과가 같다면 멱등하다고 한다.
- 서버 상태가 바뀔 수는 있지만, 같은 요청이 서버에 동일한 영향을 준다면 멱등하다고 본다.
- 캐시가능성 (Cacheable)
- 클라이언트나 중간 서버가 응답 결과를 저장하여 재사용할 수 있는 경우 캐시가 가능하다고 한다.
- 캐시 가능성은 성능 향상과 트래픽 절감에 매우 중요하다.
| 메소드 | 안전한가? | 멱등한가? | 캐시 가능한가? |
| GET | ✅ | ✅ | ✅ |
| HEAD | ✅ | ✅ | ✅ |
| POST | ❌ | ❌ | ⚠️ |
| PUT | ❌ | ✅ | ❌ |
| DELETE | ❌ | ✅ | ❌ |
| PATCH | ❌ | ⚠️ | ❌ |
6. HTTP 상태 코드
HTTP 상태 코드
- 클라이언트가 보낸 HTTP 요청에 대해 서버가 응답할 때 요청의 처리 결과를 숫자로 알려주는 표준화된 코드
- 서버가 요청을 어떻게 처리했는지 클라이언트에게 알려준다.
- 숫자 3자리로 구성되며, 앞자리 숫자에 따라 의미가 구분된다.
HTTP 상태 코드 종류
- 1xx (정보): 요청 수신, 처리 중. 거의 사용되지 않음.
- 2xx (성공): 정상 처리 완료
- 200 OK: 요청 성공
- 201 Created: 리소스 생성
- 202 Accepted: 요청 수락, 처리 중 (비동기 처리)
- 204 No Content: 성공, 응답 본문 없음
- 3xx (리다이렉션): 추가 작업 필요 (Location 헤더와 함께 사용)
- 301, 308: 영구 리다이렉션 (308은 메서드 유지)
- 302, 303, 307: 일시 리다이렉션 (303/307이 명확함)
- 304 Not Modified: 캐시 사용
- 4xx (클라이언트 에러): 요청 잘못됨
- 400: 잘못된 요청
- 401: 인증 필요
- 403: 인가 거부
- 404: 리소스 없음
- 5xx (서버 에러): 서버 문제
- 500: 내부 서버 오류
- 503: 서비스 불가, Retry-After로 복구 시간 명시 가능
* 전체 상태 코드를 외울 필요는 없고, 각 앞자리 숫자가 가진 의미만 파악하면 된다.
7. HTTP API 설계
HTTP API 설계 방법
- HTTP API는 설계시 항상 리소스 식별을 기준으로 삼아야한다.
- 위 예시에서 리소스는 게시글이다.
- URI에 들어갈 리소스는 단수 형태가 아닌 복수 형태로 사용을 권장한다. board → boards
- URL에 동사를 사용하지 않는다.
- HTTP Method의 역할을 URL에 포함하지 않는다.
예시
더보기
더보기
HTTP API 설계
- 게시글 생성
- POST
- /boards
- 성공시 상태코드 2xx
- 실패시 4xx (클라이언트 문제) OR 5xx (서버 문제)
- 게시글 1개 조회
- GET
- /boards/{id}
- 성공시 상태코드 2xx
- 실패시 4xx (클라이언트 문제) OR 5xx (서버 문제)
- 게시글 목록 조회
- GET
- /boards
- 성공시 상태코드 2xx
- 실패시 4xx (클라이언트 문제) OR 5xx (서버 문제)
- 게시글 수정
- PUT or PATCH
- /boards/{id}
- 성공시 상태코드 2xx
- 실패시 4xx (클라이언트 문제) OR 5xx (서버 문제)
- 게시글 삭제
- DELETE
- /boards/{id}
- 성공시 상태코드 2xx
- 실패시 4xx (클라이언트 문제) OR 5xx (서버 문제)
8. Header
HTTP Header
- 클라이언트와 서버가 HTTP 요청/응답에 부가적인 정보를 주고받기 위한 필드
HTTP Header 구조
- field-name: field-value 형식 (대소문자 구분 없음)
- 여러 줄로 구성되며, 각각 한 줄에 하나의 헤더
- 텍스트 기반이며 임의의 헤더도 추가 가능
대표적인 HTTP Header 종류
더보기
더보기
1. 표현 헤더 (Representation)
| 헤더 | 설명 | 예시 |
| Content-Type | 전송 데이터 형식 | application/json |
| Content-Encoding | 압축 방식 | gzip |
| Content-Language | 데이터 언어 | ko, en |
| Content-Length | 데이터 길이 (byte) | 348 |
2. 컨텐츠 협상 (Content Negotiation)
- 클라이언트가 원하는 표현 방식 지정 (요청 시 사용)
| 헤더 | 설명 | 예시 |
| Accept | 선호 미디어 타입 | application/json |
| Accept-Charset | 문자 인코딩 | utf-8 |
| Accept-Encoding | 압축 방식 | gzip |
| Accept-Language | 언어 | ko-KR, en-US;q=0.9 |
3. 일반 정보
| 헤더 | 설명 |
| From | 클라이언트 이메일 (거의 사용 안 함) |
| Referer | 이전 페이지 URL |
| User-Agent | 브라우저/디바이스 정보 |
| Server | 응답 서버 정보 |
| Date | 요청 또는 응답 발생 시간 |
4. 특별 정보
| 헤더 | 설명 |
| Host | 요청한 도메인 (필수) |
| Location | 리다이렉션 또는 생성 리소스 URI |
| Allow | 허용된 HTTP 메서드 목록 |
| Retry-After | 재요청까지의 대기 시간 (초 or 날짜) |
5. 인증
| 헤더 | 설명 |
| Authorization | 인증 정보 포함 |
| WWW-Authenticate | 필요한 인증 방법 제시 (401 응답 시) |
6. Cookie
| 헤더 | 설명 |
| Set-Cookie | 서버 → 클라이언트로 쿠키 전달 |
| Cookie | 클라이언트 → 서버로 쿠키 전송 |
| Secure | HTTPS일 때만 쿠키 전송 |
| HttpOnly | JS 접근 불가 (보안용) |
| SameSite | 동일 도메인일 경우에만 쿠키 전송 |
7. Cache
| 헤더 | 설명 |
| Cache-Control | 캐시 정책 (no-cache, no-store, max-age) |
| If-Modified-Since | 클라이언트 캐시의 수정 날짜 |
| Last-Modified | 서버 리소스 최종 수정 시간 |
| ETag | 리소스의 고유 식별자 (내용 기준) |
9. Restful API
REST
- 자원을 이름(URI)으로 구분하고, 자원의 상태(정보)를 주고받는 방식
- HTTP Method(POST, GET, PUT, DELETE 등)를 통해 자원에 대한 작업(CRUD)을 수행한다.
RESTful API
- REST 원칙을 HTTP를 통해 구현한 API이다.
- JSON 또는 XML 포맷으로 클라이언트와 서버 간 자원 상태를 주고받는다.
- REST의 규칙을 잘 따르는 HTTP API라고 정리할 수 있다.
REST URI 설계 규칙
- 리소스는 명사를 사용한다.
- 복수형을 사용한다. (예: /users)
- REST만으로 해결 불가 시, 동사 허용 가능.
- 계층 구조는 슬래시(/) 로 표현.
- 끝에 슬래시(/) 를 붙이지 않는다.
- 하이픈(-) 사용, 언더바(_) 사용 금지.
- 소문자 사용.
- 파일 확장자 포함 금지.
- CRUD는 URI에 표현하지 않고, HTTP Method 사용.
- 정렬/필터/페이징은 Query Parameter 사용.
REST 성숙도 모델 (Richardson Maturity Model)
- Level 0: URI 하나로 모든 작업 수행 (POST /operation)
- Level 1: 리소스를 URI로 구분하지만, Method는 구분하지 않음
- Level 2: HTTP Method로 작업 구분 (GET, POST, PUT, DELETE)
- Level 3: HATEOAS 적용: 응답에 다음 가능한 작업의 링크 포함
RESTful 설계 시 고려사항
- Consumer First: 사용자가 직관적으로 이해할 수 있어야 한다.
- HTTP 기능 적극 활용: Method, Status Code, Header 등을 활용한다.
- Status Code 명확히: 성공/실패 사유도 함께 제공한다.
- 보안 정보는 URI에 포함 금지.
- 명사형 리소스, 복수형 사용.
- 예외 처리는 일관된 방식으로.
'Spring > 강의' 카테고리의 다른 글
| [📕 기초 Spring] 2-1. 프레임워크와 라이브러리 (1) | 2025.05.03 |
|---|---|
| [📕 기초 Spring] 1-4. Web Application (0) | 2025.05.03 |
| [📕 기초 Spring] 용어 모음집 (0) | 2025.05.03 |
| [📕 기초 Spring] 1-2. Web 기초 (0) | 2025.05.03 |
| [📕 기초 Spring] 1-1. 네트워크 (0) | 2025.05.03 |