이번 TIL은 인프런의 "모든 개발자를 위한 HTTP 웹 기본 지식"을 학습하고, 정리한 내용입니다.
만약, 제 글의 내용을 퍼갈 시에는 " 모든 개발자를 위한 HTTP 웹 기본 지식 "도 출처에 첨부하시기 바랍니다.
HTTP 메서드의 속성
- 안전 (Safe Methods)
- 멱등 (Idempotent Methods)
- 캐시가능 (Cacheable Methods)
언제 어떤 메서드를 사용??
안전
- 호출해도 리소스를 변경하지 않는다.
- "GET"은 리소스를 변경하지 않기 때문에, 안전하다. 그러나, 그 외 "POST", "PUT", "PATCH" 등은 리소스를 수정하기 때문에 안전하지 않다.
- 즉, 호출을 했을 때, 변경이 일어나지 않는 것을 "안전"하다고 한다.
어떤 메서드들이 안전한지는 위에 표를 통해 확인해보자!!
=> 다시 말해서, "안전"은 해당 리소스가 변하는가 변하지 않는가만을 고려한다.
멱등
PUT이??
PUT은 똑같은 HTTP 메세지를 날린다고 했을 때, 한 번 날리든 2번 날리든 최종 결과가 똑같다!!
DELETE도 마찬가지!!!
그러나, POST는 얘기가 다른다.
1000원 결제 요청을 2번하면, 최종적으로 2000원이 결제된다. 즉, 최종 결과 값이 횟수마다 달라지기 때문에 POST는 멱등이 아니다.
멱등의 활용
예를 들어,
DELETE를 호출했는데, 서버에서 응답이 없다면??
그러면, 클라이언트에서 자동으로 DELETE를 재시도한다. 그래도 전혀 문제가 안된다. 왜냐면, 멱등하기 때문에!! 두려움 없이 똑같은 요청을 재시도가 가능하다.
이런 경우에는 멱등이 안될 것같은데...
예를 들어서,
재요청하는 중간에 다른 곳에서 리소스를 바꿔버렸다.
사용자 1가 GET으로 계속 조회하는데, 갑자기 사용자 2가 PUT을 해가지고 데이터를 수정한다.
그 다음에 사용자 1이 똑같은 조회를 한다면, 당연히 사용자 2가 변경한 값이 나온다.
그럼 이건 멱등이 아니지 않나?? 재요청을 하니까, 중간에 데이터가 변경됐으니까...
=> 즉, 나만 요청을 했다고 했을 때, 멱등한 것만 고려한다.
=> 물론, 현실적으로 위의 예시는 "멱등"하지 않다고 판단하는 것이 맞다!!
캐시가능
예를 들어, 웹 브라우져에 큰 사이즈의 이미지를 요청한다고 하자!!
그럼 그 다음에는 또 똑같은 리소스를 요청할 필요가 없다.
똑같은 이미지를 또 서버에서 받아오려면, 오래걸릴테니까...
그래서, 웹 브라우져가 편의성을 위해서, 내 로컬 PC에 웹 브라우져가 큰 사이즈 이미지를 저장하고 있는다. 이걸 이제 "캐시"라고 부른다. 물론, 다른 캐시들도 있지만, 간단하게 " 웹 브라우져가 내부에 해당 이미지를 저장하고 있을 수 있는가 없는가 "가 캐시가능의 개념이다.
캐시를 하려면, KEY가 맞아야 한다. 똑같은 리소스라는 KEY가 맞아야 하는데, POST는 메세지 바디 안에 데이터를 막~ 보낸다. 즉, 메세지 바디까지 고려하려면, 너무 복잡해진다. 그래서, POST로는 대부분 구현이 잘 안되있다.
PATCH 역시 메시지 바디의 내용까지 캐시 KEY로 고려해야 하기 때문에, 구현에 어려움이 많다.
GET은 URL만 딱 KEY로 잡고, 캐시를 하면 된다. 되게 간단하다.
즉, 실제로는 GET이나 HEAD만 캐시로 사용한다.
