본문으로 건너뛰기
AZ Tools

HTTP 메서드 참조

각 HTTP 메서드(GET·POST·PUT·DELETE·PATCH 등) 카드 — 안전성·idempotence·캐시 가능 여부·요청/응답 본문 허용.

GET

리소스의 표현을 가져옵니다. 부수 효과가 없어야 합니다.

Safe
예
Idempotent
예
Cacheable
예
요청 본문
아니오
응답 본문
예
HEAD

GET과 같지만 응답 본문이 없습니다. 헤더(크기, ETag, Last-Modified)를 확인할 때 씁니다.

Safe
예
Idempotent
예
Cacheable
예
요청 본문
아니오
응답 본문
아니오
POST

서버에 데이터를 보냅니다. 새 리소스를 만들거나, 폼을 전송하거나, 부수 효과가 있는 동작을 실행합니다. 명시적인 Cache-Control / Expires 헤더가 허용할 때만 캐시할 수 있습니다.

Safe
아니오
Idempotent
아니오
Cacheable
조건부
요청 본문
예
응답 본문
예
PUT

대상 리소스를 요청 페이로드로 통째로 교체합니다. 두 번 호출해도 한 번 호출한 것과 결과가 같습니다.

Safe
아니오
Idempotent
예
Cacheable
아니오
요청 본문
예
응답 본문
예
DELETE

대상 리소스를 삭제합니다. PUT과 같은 의미에서 멱등입니다. 이미 없는 리소스를 삭제해도 최종 상태는 같습니다.

Safe
아니오
Idempotent
예
Cacheable
아니오
요청 본문
조건부
응답 본문
예
PATCH

리소스를 부분적으로 수정합니다. RFC 5789는 패치 형식을 API에 맡기며, JSON Patch(RFC 6902)와 JSON Merge Patch(RFC 7396)가 흔히 쓰입니다.

Safe
아니오
Idempotent
아니오
Cacheable
아니오
요청 본문
예
응답 본문
예
OPTIONS

대상에 대해 서버가 무엇을 지원하는지 묻습니다(메서드, CORS 프리플라이트, 허용 Content-Type). 응답에는 보통 Allow 헤더가 들어 있습니다.

Safe
예
Idempotent
예
Cacheable
아니오
요청 본문
아니오
응답 본문
예
TRACE

프록시를 거친 뒤 서버가 받은 그대로 요청을 되돌려 보냅니다. 보안상(Cross-Site Tracing) 운영 환경에서는 보통 꺼 둡니다.

Safe
예
Idempotent
예
Cacheable
아니오
요청 본문
아니오
응답 본문
예
CONNECT

서버까지 터널을 엽니다. HTTP 프록시가 HTTPS를 중계할 때 씁니다. 프록시가 수락하면 클라이언트와 서버가 원시 바이트를 주고받습니다.

Safe
아니오
Idempotent
아니오
Cacheable
아니오
요청 본문
아니오
응답 본문
아니오

"조건부"는 명시적 헤더(POST의 Cache-Control·DELETE의 body) 하에서만 속성 유효.

사용법

  1. 메서드 이름(patch) 또는 키워드(cache·tunnel) 입력으로 필터링.
  2. 메서드별 카드 확인: 상단 설명·아래 5개 속성 점.
  3. 복사 버튼으로 fetch 호출·curl 명령에 메서드 넣기.

자세한 설명

펼치기

HTTP 메서드마다 카드 하나로, API 설계를 실제로 좌우하는 네 가지 성질을 정리했습니다. 안전한가(서버에서 아무것도 바꾸지 않는가), 멱등한가(반복해도 같은 최종 상태로 남는가), 캐시할 수 있는가, 그리고 요청과 응답에 본문이 허용되는가입니다. 앞의 두 가지 관계를 사람들이 자주 거꾸로 알고 있습니다. 안전하면 멱등하지만 그 역은 성립하지 않습니다. DELETE는 두 번 지워도 그 자원이 사라진 상태 그대로이므로 멱등하지만, 결코 안전하지는 않습니다. 그리고 멱등성은 응답이 아니라 서버 상태에 대한 진술입니다. 첫 번째 DELETE가 204를 반환한 자리에서 두 번째가 404를 반환해도 완전히 올바릅니다. 시간 초과된 요청을 클라이언트가 안전하게 재시도해도 되는지 판단할 때 이 점이 중요합니다.

자주 묻는 질문

POST가 같은 일 가능한데 PATCH가 별도 메서드인 이유?

의미론. PATCH는 "이 부분 diff 적용"·POST는 "이 페이로드 생성·처리". patch 포맷이 잘 설계되면 PATCH를 두 번 호출해도 한 번 호출과 같은 상태 — 이 idempotency 보장이 별도 verb 가치.

POST가 정말 캐시 가능?

조건부 — RFC 9111 §3은 응답이 명시적 Cache-Control·Expires 헤더를 가질 때 POST 응답 캐싱 허용. 실제로는 거의 아무도 이렇게 하지 않으므로 대부분 캐시가 POST를 비캐시로 처리.

두 번째 호출이 404를 돌려주면 DELETE는 멱등이 아닌가?

여전히 멱등이다. 멱등성은 요청 뒤 서버의 상태를 말하는 것이지 돌아오는 상태 코드를 말하는 것이 아니다. 한 번 지우면 리소스가 사라지고, 다시 지워도 여전히 사라진 상태다. 끝 상태가 같고, 404는 이미 참인 사실을 알려줄 뿐이다. 처음에 200을 주고 다음에도 변화 없이 200을 주는 PUT도 같은 논리다.

검색어가 URL에 넣기엔 너무 길다. POST로 바꿔야 하나?

검색을 정확히 표현하는 것은 GET이다. 안전하고, 캐시할 수 있고, 공유할 수 있다. 다만 서버와 프록시와 로그에는 현실적인 URL 길이 한계가 있고, URL에 넣은 필터는 경로상의 모든 접근 로그에 기록된다. 질의가 정말로 크거나 민감하다면 POST가 실용적인 답이다. 대신 캐싱과 동료에게 보낼 수 있는 링크를 잃는다.

관련 도구

HTTP 헤더 참조

표준 HTTP 요청·응답·CORS·캐싱·보안·쿠키 헤더 약 50개의 검색 가능한 참조.

개발

HTTP 상태 코드 레퍼런스

1xx-5xx 모든 HTTP 상태 코드 검색 — 요약·RFC·사용 시점·흔한 함정 포함.

네트워크

Git 설정 우선순위 테스터

git 설정 파일을 붙여 넣으면 키마다 어떤 값이 이기는지, 그 값이 나온 범위·파일·줄, 무엇을 덮었는지, 어떤 includeIf가 걸렸는지 보여줍니다.

개발

Base64 인코더 / 디코더

텍스트를 Base64로 인코딩하거나 다시 텍스트로 디코딩하세요.

개발

파이썬 피클 검사기

.pkl 파일을 브라우저에서 디스어셈블합니다. 오프코드 전체, 메모, 복원된 값, 그리고 불러올 때 코드가 실행되는지까지.

개발

HTTP 쿠키 파서

Cookie: 요청 헤더 또는 Set-Cookie: 응답 헤더 붙여넣기 → 각 쿠키의 이름·값·속성·경고 표시.

개발