HTTP 메서드 참조
API 설계를 실제로 형성하는 네 가지 속성 — safe(서버 부작용 없음)·idempotent(N번 반복 시 같은 결과)·cacheable(응답 재사용 가능)·body-bearing(요청·응답) — 메서드별 정리, 적합한 사용 시점 한 줄 요약 포함.
Retrieve a representation of a resource. Should have no side effects.
- Safe
- 예
- Idempotent
- 예
- Cacheable
- 예
- 요청 본문
- 아니오
- 응답 본문
- 예
Like GET but with no response body. Used to inspect headers (size, ETag, Last-Modified).
- Safe
- 예
- Idempotent
- 예
- Cacheable
- 예
- 요청 본문
- 아니오
- 응답 본문
- 아니오
Submit data to the server — create a new resource, send a form, or trigger a side-effecting action. Cacheable only when explicit Cache-Control / Expires headers permit.
- Safe
- 아니오
- Idempotent
- 아니오
- Cacheable
- 조건부
- 요청 본문
- 예
- 응답 본문
- 예
Replace the target resource entirely with the request payload. Calling it twice gives the same result as once.
- Safe
- 아니오
- Idempotent
- 예
- Cacheable
- 아니오
- 요청 본문
- 예
- 응답 본문
- 예
Remove the target resource. Idempotent in the same sense as PUT — deleting an already-gone resource still ends with the same state.
- Safe
- 아니오
- Idempotent
- 예
- Cacheable
- 아니오
- 요청 본문
- 조건부
- 응답 본문
- 예
Apply a partial update to the resource. RFC 5789 leaves the patch format up to the API — JSON Patch (RFC 6902) and JSON Merge Patch (RFC 7396) are the common choices.
- Safe
- 아니오
- Idempotent
- 아니오
- Cacheable
- 아니오
- 요청 본문
- 예
- 응답 본문
- 예
Ask what the server supports for the target — methods, CORS preflight, accepted Content-Types. The response usually carries an Allow header.
- Safe
- 예
- Idempotent
- 예
- Cacheable
- 아니오
- 요청 본문
- 아니오
- 응답 본문
- 예
Echo back the request as the server sees it after proxies. Usually disabled in production for security (Cross-Site Tracing).
- Safe
- 예
- Idempotent
- 예
- Cacheable
- 아니오
- 요청 본문
- 아니오
- 응답 본문
- 예
Establish a tunnel to the server, used by HTTP proxies for HTTPS. The client and server exchange raw bytes after the proxy accepts.
- Safe
- 아니오
- Idempotent
- 아니오
- Cacheable
- 아니오
- 요청 본문
- 아니오
- 응답 본문
- 아니오
"조건부"는 명시적 헤더(POST의 Cache-Control·DELETE의 body) 하에서만 속성 유효.
사용법
- 메서드 이름(`patch`) 또는 키워드(`cache`·`tunnel`) 입력으로 필터링.
- 메서드별 카드 확인: 상단 설명·아래 5개 속성 점.
- 복사 버튼으로 fetch 호출·curl 명령에 메서드 넣기.
자주 묻는 질문
- 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·사용 시점·흔한 함정 포함.
Base64 인코더 / 디코더
텍스트를 Base64로 인코딩하거나 다시 텍스트로 디코딩하세요.
HTTP 쿠키 파서
`Cookie:` 요청 헤더 또는 `Set-Cookie:` 응답 헤더 붙여넣기 → 각 쿠키의 이름·값·속성·경고 표시.
ASCII 코드 표
256행 ASCII / 확장 ASCII 표 — 10진·16진·8진·2진 + 제어 문자 이름. 검색·복사.
MIME 타입 조회
확장자로 MIME 타입을 찾거나 그 반대로 조회. 각 타입의 용도 설명.