PUT은 리소스 전체를 교체합니다—필드를 빠뜨리면 그 필드는 사라집니다. PATCH는 지정한 것만 수정합니다. 어떤 메서드를 선택하느냐에 따라 언급하지 않은 필드들의 운명이 결정됩니다.
DELETE는 멱등적입니다—영원히 호출할 수 있습니다—하지만 파괴는 단 한 번만 일어납니다. 이 긴장 관계가 모든 구현 결정을 형성합니다.
GET 요청은 질문입니다—아무것도 변경하지 않고 데이터를 가져옵니다. 이 단순한 규칙이 캐싱, 프리페치, 자동 재시도를 가능하게 합니다. 이 규칙을 어기면, 브라우저가 사용자의 계정을 삭제할 수도 있습니다.
POST는 데이터를 가져오는 게 아니라 서버에 행동을 요청합니다. 이 차이를 이해하는 것이 폼, API, 안전한 웹 애플리케이션의 핵심입니다.
CONNECT는 HTTPS 터널링을 위해 프록시를 단순 통로로 만듭니다. TRACE는 디버깅을 위해 요청을 그대로 돌려주지만, 그 투명성이 보안 취약점이 되어버렸습니다. 서로 다른 운명을 맞이한 두 가지 특수 HTTP 메서드.
HEAD는 정찰입니다—파일을 직접 받지 않고도 서버에 리소스를 설명해달라고 요청합니다. 콘텐츠를 단 한 바이트도 전송받지 않고 파일 크기를 확인하고, 링크를 검증하고, 캐시 유효성을 확인할 수 있습니다.
네트워크는 요청이 성공했는지 알려주지 않습니다—응답을 받았는지 알려줄 뿐입니다. 멱등성은 이 불확실성을 다루는 시스템을 구축하는 방법입니다.
OPTIONS는 서버에 '여기서 뭘 할 수 있나요?'라고 묻습니다. 하지만 진짜 역할은 더 흥미롭습니다: 브라우저가 신뢰하지 않는 JavaScript를 대신해 허가를 구하는 것입니다.
HTTP 메서드는 결과에 대한 약속입니다. GET은 '나는 오직 볼 것입니다'라고 말하고, POST는 '무언가가 변경될 것입니다'라고 말합니다. 이 계약들을 이해하면 브라우저가 양식을 새로고침하기 전에 경고를 띄우는 이유, 일부 요청은 캐시할 수 있고 다른 것은 그렇지 않은 이유, 그리고 웹 전체가 어떻게 일관성을 유지하는지 알 수 있습니다.
이 페이지가 도움이 되었나요?