🚦 HTTP 메서드 선택 가이드 | 어떤 걸 써야 할까?

1. 요청으로 하려는 일

2. 네트워크 오류 때 같은 요청을 자동 재시도해야 하나?

표준 메서드 9개의 규격 속성

메서드	안전	멱등	캐시	요청 본문
GET	O	O	O	의미 없음
HEAD	O	O	O	의미 없음
POST	X	X	조건부	사용
PUT	X	O	X	사용
DELETE	X	O	X	의미 없음
CONNECT	X	X	X	보내지 않음
OPTIONS	O	O	X	의미 없음
TRACE	O	O	X	보내지 않음
PATCH	X	X	조건부	사용

PATCH 를 뺀 8개는 RFC 9110, PATCH 는 RFC 5789 가 정의한다. 표의 값은 두 규격이 직접 정한 속성이며 이 페이지에서 만든 기준이 아니다. '조건부'는 응답에 명시적 신선도 정보와 요청 URI 와 같은 Content-Location 이 함께 있을 때만 캐시할 수 있다는 뜻이다.

HTTP 메서드, 용도별로 무엇을 고를까

REST API 를 만들 때 가장 먼저 막히는 지점이 메서드 선택이다. 위에서 하려는 일과 재시도 조건 두 가지만 고르면 그 용도에 쓰는 메서드와 함께 안전·멱등·캐시 가능 여부, 요청 본문을 쓰는지까지 한 화면에 나온다. 아래 표는 표준 메서드 9개를 같은 기준으로 나란히 놓은 것이다.

안전은 읽기만 하고 서버 상태를 바꾸지 않는다는 뜻이고, 멱등은 같은 요청을 여러 번 보내도 서버 상태의 결과가 한 번 보낸 것과 같다는 뜻이다. 이 두 속성과 캐시 가능 여부는 GET·HEAD·POST·PUT·DELETE·CONNECT·OPTIONS·TRACE 를 정의한 RFC 9110 과 PATCH 를 정의한 RFC 5789 가 직접 정한 값이다. 2026년 10월 기준 규격 내용이며, 이 페이지가 임의로 매긴 등급이 아니다.

이 도구는 규격에 적힌 속성을 보여 줄 뿐, 특정 프레임워크나 서버가 실제로 그 메서드를 허용하는지는 판단하지 않는다. 프록시·방화벽·게이트웨이가 PATCH 나 TRACE 를 막는 경우가 흔하므로 운영 환경에서 직접 확인해야 한다. 상태 코드 선택, 헤더 설계, 인증 방식은 다루지 않는다.

자주 묻는 질문

POST 와 PUT 은 어떻게 구분할까?

새 자원의 위치를 서버가 정하면 POST, 클라이언트가 URI 를 정하고 그 내용을 통째로 대체하면 PUT 이다. PUT 은 멱등이라 재시도에 안전하고 POST 는 그렇지 않다.

PATCH 는 왜 멱등이 아닐까?

패치 문서에 "값을 1 더해라" 처럼 현재 상태에 의존하는 지시를 담을 수 있어서다. 규격이 멱등을 보장하지 않으므로 재시도가 필요하면 조건부 요청으로 보호한다.

GET 요청에 본문을 넣어도 될까?

규격이 GET 본문에 정의된 의미를 두지 않았고 중간 서버가 버리거나 거부할 수 있다. 조건이 길면 질의 문자열이나 POST 를 쓰는 편이 안전하다.

🚦HTTP 메서드 선택 가이드

표준 메서드 9개의 규격 속성

관련된 도구

HTTP 상태 코드 검색

cURL 명령어 생성기

HTTP 메서드, 용도별로 무엇을 고를까

자주 묻는 질문

표준 메서드 9개의 규격 속성

관련된 도구

HTTP 상태 코드 검색

cURL 명령어 생성기

HTTP 메서드, 용도별로 무엇을 고를까

자주 묻는 질문

같은 카테고리 도구