HTTP 메서드

작성자

익명

작성일

2026.07.10

조회수

버전

HTTP 메서드 (HTTP Methods)

1. 개요

HTTP 메서드는 클라이언트가 서버에 요청을 보낼 때, 해당 요청의 목적(의도)을 정의하는 HTTP 프로토콜의 핵심 요소이다. 클라이언트-서버 모델을 기반으로 하며, 요청 메시지의 시작 부분에 위치하여 서버가 수행해야 할 동작을 명시한다. 예를 들어, 단순히 정보를 조회하려는 것인지, 새로운 데이터를 생성하려는 것인지, 혹은 기존 데이터를 수정하거나 삭제하려는 것인지에 따라 서로 다른 메서드를 사용함으로써 서버는 요청의 의도를 정확히 파악하고 적절한 비즈니스 로직을 수행할 수 있다.

2. 주요 메서드 상세

가장 빈번하게 사용되는 핵심 메서드들은 리소스(Resource, 서버가 제공하는 정보의 단위)의 생성, 조회, 수정, 삭제라는 CRUD(Create, Read, Update, Delete) 작업과 밀접하게 연관되어 있다.

2.1 핵심 메서드 정의

GET: 서버로부터 특정 리소스를 조회하기 위해 사용한다. 요청 본문(Body)을 포함하지 않으며, URL의 쿼리 스트링을 통해 데이터를 전달한다.
POST: 서버에 새로운 리소스를 생성하거나, 데이터를 처리하기 위해 사용한다. 주로 데이터 전송이나 파일 업로드 시 사용되며, 요청 본문에 데이터를 담아 보낸다.
PUT: 서버의 특정 리소스를 완전히 대체(Replace)하기 위해 사용한다. 요청 본문에 리소스의 전체 상태를 담아 보내며, 해당 리소스가 없으면 새로 생성하기도 한다.
PATCH: 리소스의 일부를 수정(Partial Update)하기 위해 사용한다. 변경이 필요한 필드만 요청 본문에 포함하여 전송한다.
DELETE: 특정 리소스를 삭제하기 위해 사용한다.

2.2 메서드 비교 및 상태 코드 매핑

메서드	목적	요청 본문(Body)	성공 시 주요 응답 코드	특징
GET	리소스 조회	$\times$	`200 OK`	캐싱 가능, 브라우저 기록 남음
POST	리소스 생성/처리	$\circ$	`201 Created`	비멱등성, 서버 상태 변경
PUT	리소스 전체 교체	$\circ$	`200 OK`, `204 No Content`	멱등성, 전체 데이터 전송 필요
PATCH	리소스 부분 수정	$\circ$	`200 OK`, `204 No Content`	멱등성 보장 안 됨(설계에 따라 다름)
DELETE	리소스 삭제	$\times$ (선택적)	`200 OK`, `204 No Content`	멱등성, 리소스 제거

3. 메서드의 특성 (멱등성과 안전성)

HTTP 메서드를 올바르게 사용하기 위해서는 '안전성'과 '멱등성'이라는 두 가지 개념을 이해해야 한다.

3.1 안전성 (Safe)

안전한 메서드란 호출했을 때 서버의 상태(데이터)를 변경하지 않는 메서드를 의미한다. 즉, 읽기 전용(Read-only) 작업이다. * 해당 메서드: GET, <a href="/doc/%EA%B8%B0%EC%88%A0/%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC/%EC%97%B0%EA%B2%B0%20%EA%B8%B0%EC%88%A0/HEAD" class="wiki-link wiki-link-missing">HEAD</a>, <a href="/doc/%EA%B8%B0%EC%88%A0/%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC/%EC%97%B0%EA%B2%B0%20%EA%B8%B0%EC%88%A0/OPTIONS" class="wiki-link wiki-link-missing">OPTIONS</a> * 논리적 근거: 이 메서드들은 리소스를 조회하거나 메타데이터를 확인하는 용도로만 사용되므로, 여러 번 호출하더라도 서버의 데이터베이스 상태가 변하지 않는다.

3.2 멱등성 (Idempotent)

멱등한 메서드란 동일한 요청을 한 번 보내는 것과 여러 번 연속해서 보내는 것이 서버 상태에 동일한 영향을 미치는 성질을 의미한다. * 해당 메서드: GET, PUT, DELETE, HEAD, OPTIONS * 논리적 근거: * GET: 여러 번 조회해도 데이터는 변하지 않는다. * PUT: 동일한 전체 데이터를 여러 번 덮어써도 최종 결과는 동일한 상태로 유지된다. * DELETE: 이미 삭제된 리소스를 다시 삭제 요청해도 결과적으로 리소스가 없는 상태는 동일하다. * 비멱등성 메서드 (POST, PATCH): POST는 동일한 요청을 여러 번 보낼 경우, 서버에 동일한 내용의 리소스가 여러 개 생성되므로 서버의 상태가 매번 변하게 된다. PATCH는 구현 방식(예: 값 증가 연산)에 따라 결과가 달라질 수 있어 일반적으로 비멱등적으로 간주한다.

4. 메서드 선택 가이드 (REST API 설계)

REST(Representational State Transfer) API 설계 시, 리소스의 상태 변경 목적에 따라 PUT과 PATCH를 엄격히 구분하여 사용하는 것이 권장된다.

4.1 PUT vs PATCH 비교 예제

사용자의 프로필 정보 중 '이름'과 '이메일'이 있고, 이 중 '이메일'만 수정하려는 경우의 차이는 다음과 같다.

[PUT] 전체 교체 방식 전체 필드를 모두 보내야 하며, 누락된 필드는 null이나 기본값으로 덮어씌워질 위험이 있다.

// REQUEST: PUT /users/123
{
  "name": "홍길동", 
  "email": "new-email@example.com" 
}
// 결과: name과 email 모두 업데이트됨

[PATCH] 부분 수정 방식 변경이 필요한 필드만 전송하여 효율적이며, 기존 데이터를 보존한다.

// REQUEST: PATCH /users/123
{
  "email": "new-email@example.com"
}
// 결과: email만 업데이트되고 name은 유지됨

4.2 REST API 설계 안티패턴

설계 시 다음과 같은 잘못된 관행(Anti-pattern)을 주의해야 한다. 1. 동사 기반의 URI 사용: /getUser, /updateUser와 같이 URI에 행위를 포함하는 것. (올바른 예: GET /users, PATCH /users/{id}) 2. 모든 요청에 POST 사용: 편의를 위해 모든 API를 POST로 처리하는 방식. 이는 HTTP 프로토콜의 시맨틱(Semantic)을 무시하며, 캐싱 및 네트워크 최적화 혜택을 누릴 수 없게 만든다. 3. GET 요청으로 상태 변경: GET /delete-user?id=1과 같이 조회 메서드로 데이터를 삭제하거나 수정하는 행위. 이는 검색 엔진 크롤러나 브라우저 프리페칭(Prefetching)에 의해 의도치 않은 데이터 변경이 일어날 수 있어 매우 위험하다.

5. 기타 메서드 및 주의사항

5.1 특수 목적 메서드

HEAD: GET과 동일하지만, 응답 본문(Body)을 제외하고 헤더 정보만 반환한다. 리소스의 존재 여부나 수정 날짜를 확인할 때 사용한다.
OPTIONS: 대상 리소스에 대해 서버가 허용하는 HTTP 메서드 목록을 확인하기 위해 사용한다. CORS(Cross-Origin Resource Sharing) 상황에서 브라우저가 보내는 'Preflight' 요청에 주로 쓰인다.
TRACE: 요청이 서버에 도달하기까지 거치는 경로를 테스트하기 위해 사용하며, 서버가 받은 요청을 그대로 반환한다.

5.2 보안 및 제약 사항

보안 위험: TRACE 메서드는 서버 내부 정보가 노출될 수 있어 보안 설정(XSS 공격 등)을 통해 대부분의 운영 서버에서 비활성화한다.
지원 범위: 오래된 브라우저나 일부 프록시 서버, 방화벽에서는 PUT, DELETE, PATCH 메서드를 차단하는 경우가 있다. 이 경우 POST 메서드를 사용하고 HTTP 헤더에 X-HTTP-Method-Override를 추가하여 메서드를 오버라이딩(Overriding)하는 방식을 사용하기도 한다.

6. 참고: HTTP 버전별 전송 효율성

HTTP 버전이 올라가더라도 메서드의 의미(Semantics)는 변하지 않으나, 이를 전송하는 효율성(Transport)이 개선되어 더 많은 API 요청을 빠르게 처리할 수 있게 되었다.

구분	HTTP/1.1	HTTP/2	HTTP/3
메서드 정의	표준 메서드 정의 및 확립	메서드 정의는 동일함	메서드 정의는 동일함
전송 방식	텍스트 기반, 순차적 전송	바이너리 프레임, 멀티플렉싱	QUIC 기반, UDP 전송
영향	메서드별 요청-응답 대기 시간 발생 (HOL Blocking)	여러 메서드 요청을 동시에 처리하여 성능 향상	패킷 손실 시에도 다른 스트림에 처리

📝 마크다운 원본

이 문서의 마크다운 원본 내용입니다.

# HTTP 메서드 (HTTP Methods)

## 1. 개요
HTTP 메서드는 클라이언트가 서버에 요청을 보낼 때, 해당 요청의 목적(의도)을 정의하는 HTTP 프로토콜의 핵심 요소이다. 클라이언트-서버 모델을 기반으로 하며, 요청 메시지의 시작 부분에 위치하여 서버가 수행해야 할 동작을 명시한다. 예를 들어, 단순히 정보를 조회하려는 것인지, 새로운 데이터를 생성하려는 것인지, 혹은 기존 데이터를 수정하거나 삭제하려는 것인지에 따라 서로 다른 메서드를 사용함으로써 서버는 요청의 의도를 정확히 파악하고 적절한 비즈니스 로직을 수행할 수 있다.

## 2. 주요 메서드 상세
가장 빈번하게 사용되는 핵심 메서드들은 리소스(Resource, 서버가 제공하는 정보의 단위)의 생성, 조회, 수정, 삭제라는 CRUD(Create, Read, Update, Delete) 작업과 밀접하게 연관되어 있다.

### 2.1 핵심 메서드 정의
*   **GET**: 서버로부터 특정 리소스를 조회하기 위해 사용한다. 요청 본문(Body)을 포함하지 않으며, URL의 쿼리 스트링을 통해 데이터를 전달한다.
*   **POST**: 서버에 새로운 리소스를 생성하거나, 데이터를 처리하기 위해 사용한다. 주로 데이터 전송이나 파일 업로드 시 사용되며, 요청 본문에 데이터를 담아 보낸다.
*   **PUT**: 서버의 특정 리소스를 완전히 대체(Replace)하기 위해 사용한다. 요청 본문에 리소스의 전체 상태를 담아 보내며, 해당 리소스가 없으면 새로 생성하기도 한다.
*   **PATCH**: 리소스의 일부를 수정(Partial Update)하기 위해 사용한다. 변경이 필요한 필드만 요청 본문에 포함하여 전송한다.
*   **DELETE**: 특정 리소스를 삭제하기 위해 사용한다.

### 2.2 메서드 비교 및 상태 코드 매핑
| 메서드 | 목적 | 요청 본문(Body) | 성공 시 주요 응답 코드 | 특징 |
| :--- | :--- | :---: | :---: | :--- |
| **GET** | 리소스 조회 | $\times$ | `200 OK` | 캐싱 가능, 브라우저 기록 남음 |
| **POST** | 리소스 생성/처리 | $\circ$ | `201 Created` | 비멱등성, 서버 상태 변경 |
| **PUT** | 리소스 전체 교체 | $\circ$ | `200 OK`, `204 No Content` | 멱등성, 전체 데이터 전송 필요 |
| **PATCH** | 리소스 부분 수정 | $\circ$ | `200 OK`, `204 No Content` | 멱등성 보장 안 됨(설계에 따라 다름) |
| **DELETE** | 리소스 삭제 | $\times$ (선택적) | `200 OK`, `204 No Content` | 멱등성, 리소스 제거 |

## 3. 메서드의 특성 (멱등성과 안전성)
HTTP 메서드를 올바르게 사용하기 위해서는 '안전성'과 '멱등성'이라는 두 가지 개념을 이해해야 한다.

### 3.1 안전성 (Safe)
**안전한 메서드**란 호출했을 때 서버의 상태(데이터)를 변경하지 않는 메서드를 의미한다. 즉, 읽기 전용(Read-only) 작업이다.
*   **해당 메서드**: `GET`, `HEAD`, `OPTIONS`
*   **논리적 근거**: 이 메서드들은 리소스를 조회하거나 메타데이터를 확인하는 용도로만 사용되므로, 여러 번 호출하더라도 서버의 데이터베이스 상태가 변하지 않는다.

### 3.2 멱등성 (Idempotent)
**멱등한 메서드**란 동일한 요청을 한 번 보내는 것과 여러 번 연속해서 보내는 것이 서버 상태에 동일한 영향을 미치는 성질을 의미한다.
*   **해당 메서드**: `GET`, `PUT`, `DELETE`, `HEAD`, `OPTIONS`
*   **논리적 근거**:
    *   `GET`: 여러 번 조회해도 데이터는 변하지 않는다.
    *   `PUT`: 동일한 전체 데이터를 여러 번 덮어써도 최종 결과는 동일한 상태로 유지된다.
    *   `DELETE`: 이미 삭제된 리소스를 다시 삭제 요청해도 결과적으로 리소스가 없는 상태는 동일하다.
*   **비멱등성 메서드 (`POST`, `PATCH`)**: `POST`는 동일한 요청을 여러 번 보낼 경우, 서버에 동일한 내용의 리소스가 여러 개 생성되므로 서버의 상태가 매번 변하게 된다. `PATCH`는 구현 방식(예: 값 증가 연산)에 따라 결과가 달라질 수 있어 일반적으로 비멱등적으로 간주한다.

## 4. 메서드 선택 가이드 (REST API 설계)
REST(Representational State Transfer) API 설계 시, 리소스의 상태 변경 목적에 따라 `PUT`과 `PATCH`를 엄격히 구분하여 사용하는 것이 권장된다.

### 4.1 PUT vs PATCH 비교 예제
사용자의 프로필 정보 중 '이름'과 '이메일'이 있고, 이 중 '이메일'만 수정하려는 경우의 차이는 다음과 같다.

**[PUT] 전체 교체 방식**
전체 필드를 모두 보내야 하며, 누락된 필드는 `null`이나 기본값으로 덮어씌워질 위험이 있다.
```json
// REQUEST: PUT /users/123
{
  "name": "홍길동", 
  "email": "new-email@example.com" 
}
// 결과: name과 email 모두 업데이트됨
```

**[PATCH] 부분 수정 방식**
변경이 필요한 필드만 전송하여 효율적이며, 기존 데이터를 보존한다.
```json
// REQUEST: PATCH /users/123
{
  "email": "new-email@example.com"
}
// 결과: email만 업데이트되고 name은 유지됨
```

### 4.2 REST API 설계 안티패턴
설계 시 다음과 같은 잘못된 관행(Anti-pattern)을 주의해야 한다.
1.  **동사 기반의 URI 사용**: `/getUser`, `/updateUser`와 같이 URI에 행위를 포함하는 것. (올바른 예: `GET /users`, `PATCH /users/{id}`)
2.  **모든 요청에 POST 사용**: 편의를 위해 모든 API를 `POST`로 처리하는 방식. 이는 HTTP 프로토콜의 시맨틱(Semantic)을 무시하며, 캐싱 및 네트워크 최적화 혜택을 누릴 수 없게 만든다.
3.  **GET 요청으로 상태 변경**: `GET /delete-user?id=1`과 같이 조회 메서드로 데이터를 삭제하거나 수정하는 행위. 이는 검색 엔진 크롤러나 브라우저 프리페칭(Prefetching)에 의해 의도치 않은 데이터 변경이 일어날 수 있어 매우 위험하다.

## 5. 기타 메서드 및 주의사항

### 5.1 특수 목적 메서드
*   **HEAD**: `GET`과 동일하지만, 응답 본문(Body)을 제외하고 헤더 정보만 반환한다. 리소스의 존재 여부나 수정 날짜를 확인할 때 사용한다.
*   **OPTIONS**: 대상 리소스에 대해 서버가 허용하는 HTTP 메서드 목록을 확인하기 위해 사용한다. CORS(Cross-Origin Resource Sharing) 상황에서 브라우저가 보내는 'Preflight' 요청에 주로 쓰인다.
*   **TRACE**: 요청이 서버에 도달하기까지 거치는 경로를 테스트하기 위해 사용하며, 서버가 받은 요청을 그대로 반환한다.

### 5.2 보안 및 제약 사항
*   **보안 위험**: `TRACE` 메서드는 서버 내부 정보가 노출될 수 있어 보안 설정(XSS 공격 등)을 통해 대부분의 운영 서버에서 비활성화한다.
*   **지원 범위**: 오래된 브라우저나 일부 프록시 서버, 방화벽에서는 `PUT`, `DELETE`, `PATCH` 메서드를 차단하는 경우가 있다. 이 경우 `POST` 메서드를 사용하고 HTTP 헤더에 `X-HTTP-Method-Override`를 추가하여 메서드를 오버라이딩(Overriding)하는 방식을 사용하기도 한다.

## 6. 참고: HTTP 버전별 전송 효율성
HTTP 버전이 올라가더라도 메서드의 의미(Semantics)는 변하지 않으나, 이를 전송하는 효율성(Transport)이 개선되어 더 많은 API 요청을 빠르게 처리할 수 있게 되었다.

| 구분 | HTTP/1.1 | HTTP/2 | HTTP/3 |
| :--- | :--- | :--- | :--- |
| **메서드 정의** | 표준 메서드 정의 및 확립 | 메서드 정의는 동일함 | 메서드 정의는 동일함 |
| **전송 방식** | 텍스트 기반, 순차적 전송 | 바이너리 프레임, 멀티플렉싱 | QUIC 기반, UDP 전송 |
| **영향** | 메서드별 요청-응답 대기 시간 발생 (HOL Blocking) | 여러 메서드 요청을 동시에 처리하여 성능 향상 | 패킷 손실 시에도 다른 스트림에 처리 |

AI 생성 콘텐츠 안내

이 문서는 AI 모델(gemma-4-31b)에 의해 생성된 콘텐츠입니다.

주의사항: AI가 생성한 내용은 부정확하거나 편향된 정보를 포함할 수 있습니다. 중요한 결정을 내리기 전에 반드시 신뢰할 수 있는 출처를 통해 정보를 확인하시기 바랍니다.

위키너와나