HTTP를 배워보자 5일차 - HTTP 메서드

 

1. 서론

저번 시간에는 HTTP의 기본적인 특징에 대해 살펴보았다. 

대표적으로 무상태, 비연결성 등이 있었고, 이들은 지금까지 HTTP를 계속 사용할 수 있는 기반이 되었다.

 

필자는 1학년 때 함수와 메서드라는 단어를 처음 배우면서 게임 안의 캐릭터의 스킬이랑 매칭 시켜 이해했는데,

HTTP도 비슷하다. 지금까지는 특성(스텟)에 대해 배웠다면, 스킬(행동)에 대해 공부해보자.

 

 

2. HTTP 요청 메서드의 종류

제목은 HTTP 메서드라고했지만, MDN Web Docs 에서는 요청 메서드라고 한다.

 

 

1) GET

 

리소스를 조회한다.

보통 쿼리를 통해 전달하는데, 앞 장에서 설명했듯이 이런 방식이다. (?key1=value1&key2=value2)

 

동작 방식

 

메시지 전달(GET 메서드 사용) -> 서버 도착 -> 서버에서 클라이언트로 응답(Response) 데이터 전송

 

 

2) POST

 

메시지 바디를 통해 서버로 요청 데이터를 전달한다.

주로 신규 회원을 등록하거나, 프로세스 처리에 사용된다.

 

동작 방식

 

 메시지 전달(POST 메서드 사용) -> 서버에서 새 리소스 생성(등록) -> 요청 데이터 처리

 

특히 POST는 이 과정에서 단순히 데이터가 생성되거나, 변경되는 것들을 넘어 프로세스의 상태가 변경될 수 있다.

예를 들어 택배 배송과 같은 상황에서 [출고] -> [운송장 집하] -> [도착] 이런 상태를 의미한다.

 

 

 

3) PUT

 

리소스를 대체한다.

만약 해당 리소스가 없으면 생성하고, 있으면 대체하는.. 그냥 생각 없이 덮어버린다고 생각하자.

 

POST와의 차이점은 PUT 메서드는 자원의 식별자를 이미 알고 있는 상태여야 한다는 점이다. 이 부분이 어려운데,

POST는 요청 메시지로 포함된 엔티티를 이용해 새로운 자원을 생성해 내는 것이고, 

PUT은 요청 메시지와 함께 넘어온 식별자의 자원을 만드는 것이다.

 

따라서 완전히 똑같은 요청이 두 번 날아오면, POST는 데이터가 2개 만들어지고,

PUT은 처음엔 데이터가 만들어지지만, 두 번째는 자원을 생성하지 않고 교체하게 된다.

이러한 PUT의 특징은 idempotent(멱등)이라고 한다. 간단하게 한 번하나 여러 번하나 결과가 같게 나온다는 의미이다.

 

 

 

4) PATCH

 

리소스를 부분적으로 대체한다.

 

만약 스텟으로 (힘, 방어력, 체력)이 있는 캐릭터가 있다고 하자.

이때 방어력만 상승한 경우 PATCH를 쓰게 된다.

 

만약 이 경우 PATCH 요청 메시지에 (방어력 : 50)만 보내게 되면 정확히 그 부분만 바뀌게 되는 것이다.

 

반면에 PUT 요청 메시지에 (방어력 : 50)을 보내면 기존에 있던 (힘, 체력) 부분은 null 또는 초기값으로 바뀌어 버린다. 꼭 주의해야 한다!

 

 

5) DELETE

 

리소스를 제거한다.

 

이 밖에도 HEAD, CONNECT, OPTIONS, TRACE 가 있는데, 이 부분은 생략하도록 하겠다.

 

 

 

3. HTTP 메서드의 속성

 

출처 - https://ko.wikipedia.org/wiki/HTTP

 

위 그림은 위키피디아에 나와있는 각 메서드의 속성 표이다.

 

 

1) 안전

 

계속 호출해도 리소스가 변경되지 않는다.

아까 배운 것들 중에서는 GET이 유일하다. 나머지는 리소스를 삽입, 수정, 삭제하기 때문이다.

 

2) 멱등

 

위에 PUT 설명에서 잠깐 언급했는데, 한 번 호출하던 100번 호출하던 결과가 똑같은 성질이다.

GET, DELETE도 마찬가지로 조회나 삭제는 여러 번해도 똑같다. 하지만 POST는 여러 데이터가 생성되므로 다르다.

 

이 부분은 이후 Timeout 상태가 발생한 경우 복구 요청을 다시 보내도 되는가?라는 판단의 기준이 되기도 한다.

 

3) 캐시

 

응답 결과 리소스를 캐시 해서 사용해도 되는지 여부를 판단한다.

일반적으로 GET 메서드를 통해 가져온 리소스들을 캐싱하고, MDN 문서에서는 심지어 GET만 해당하는 것처럼 쓰여있다.

 

이유는 POST, PATCH도 가능은하지만, 이게 본문 메시지까지 캐시 키로 고려하기엔 구현이 쉽지가 않다고 한다.

따라서 GET 정도만 캐시 여부를 고려하면 될 것 같다.