이 포스트는 “HTTP 완벽 가이드”의 “3장.HTTP 메시지”의 일부를 정리한 내용으로 이루어져 있습니다.

메서드

클라이언트 쪽에서 서버로 요청하는 메세지의 형식은 다음과 같다.

<메서드> <요청 URL> <버전>
<헤더>

<엔티티 본문>

클라이언트 요청의 처음에 위치한 메서드에 대해서 알아본다. 메서드는 클라이언트 측에서 서버가 리소스에 대해 수행해주길 바라는 동작이다. 모든 서버가 모든 메서드를 구현하지는 않는다. HTTP 버전 1.1과 호환 되고자 한다면 서버는 GET, HEAD 메서드만을 구현하는 것만으로도 충분한다.

안전한 메서드(Safe Method)

HTTP는 안전한 메서드라 불리는 메서드의 집합을 정의한다. GET과 HEAD 메서드는 HTTP 요청의 결과로 서버에 어떤 작용도 하지 않는다. 그래서 GET, HEAD 메서드는 안전하다고 할 수 있다. 하지만 안전한 메서드가 서버에 작용을 유발하지 않는다는 보장은 없다. 그것은 웹개발자에게 달려 있다. 안전한 메서드의 목적은 서버에 영향을 줄 수 있는 안전하지 않은 메서드가 사용될 때 사용자들에게 알려줄 수 있는 HTTP 어플리케이션을 만드는데 있다.

GET

가장 흔히 쓰에는 메서이다. 주로 서버에 리소스를 달라고 요청할 때 쓰인다.

HEAD

HEAD 메서드는 GET처럼 동작하지만 응답으로 헤더만을 돌려준다. HEAD를 사용하면 리소스를 가져오지 않고도 그 대해 알 수 있고, 응답의 상태코드를 통해 개체의 존재를 확인할 수 있고, 헤더를 확인하여 리소스가 변경되었는지 검사할 수 있다. HTTP/1.1 준수를 위해서는 HEAD 메서드가 반드시 구현되어 있어야 한다.

PUT

PUT 메서드는 서버에 문서를 쓴다. PUT 메서드는 서버가 요청의 본문을 가지고 요청 URL의 이름대로 새 문서를 만들거나, 이미 URL이 존재한다면 본문을 사용해서 교체하라는 의미를 가진다. PUT 메서드는 콘텐츠를 변경할 수 있기 때무넹, PUT을 수행하기 전에 사용자 인증 과정을 거친다.

POST

서버에 입력 데이터를 전송하기 위해 설계되었다. HTML폼을 지원하기 위해 흔히 사용된다.

TRACE

클라이언트의 요청은 방화벽, 프락시, 게이트웨이 등의 어플리케이션을 통과할 수 있다. 각 요소들은 원래의 HTTP 요청을 수정할 수 있다. TRACE 메서드는 클라이언트에게 자신의 요청이 서버에 도달했을 때 어떻게 보이게 되는지 알려준다. TRACE는 진단을 위해 사용할 때는 괜찮지만 중간 어플리케이션들이 여러 종류의 메서드들에 대해 일관된 동작을 한다는 가정을 전제로 한다. 하지만 많은 HTTP 어플리케이션들을 메서드에 따라 다르게 동작한다. 예를 들면 프락시는 POST 요청을 바로 서버로 통과시키는 반면 GET 요청은 웹 캐시와 같은 다른 HTTP 어플리케이션으로 전송한곤 한다.

OPTIONS

OPTIONS 메서드는 웹 서버가 어떤 종류의 메서드를 지원하는지 확인한다. 이 메서드는 여러 리소스에 대해 실제로 접근하지 않고, 리소스에 접근할 수 있는 수단을 클라이언트에게 제공한다.

DELETE

URL에 해당하는 리소스를 삭제할 것을 요청한다. 그러나 클라이언트는 삭제가 수행되는 것을 보장하지 못한다. HTTP 명세에서는 서버가 클라이언트에게 알리지 않고 요청을 무시하는 것을 허용하기 때문이다.

확장 메서드

HTTP는 필요에 따라 확장해도 문제가 없도록 설계되어있다. 모든 확장 메서드가 형식을 갖춘 명세로 정의되지 않는다. 누군가 정의한 확장메서드는 대부분의 HTTP 어플리케이션이 이해할 수 없을 것이다. 이런 상황에서는 확장 메서드에 대해 관용적인 것이 최고다. 확장 메서드를 다룰 때는 “엄격하게 보내고 관대하게 받아들여라”라는 오랜 규칙을 따르는 것이 좋다.

출처: "HTTP 완벽가이드", 이응준, 정상일 옮김, 인사이트, 2014