인프런 커뮤니티 질문&답변

응답 결과 리소스를 캐시해서 사용해도 되야 캐시 기능을 편하게 사용할 수 있다. GET의 경우 만약 요청 메세지가 같다면 굳이 통신까지 사용해서 서버에서 응답을 받을 것이 아니라 이전 응답에 의한 응답 메세지가 캐싱되어있다면 캐시에서 꺼내올 수 있을 것이다. 이러한 방식을 완전 캐시 히트 (Full Cache Hit)라고 한다.

캐시를 활용하여 서버와의 최소한의 통신만 하는 조건부 요청이 가능하다. 만약 캐시를 이용할 수 있는 GET요청이지만 이전 요청과 요청조건이 다르다면 서버와의 최소한의 통신으로 응답이 같을 건지 확인하고 같을 것이라면 캐시에서 이전 응답을 꺼내오는 것이다.

POST를 생각해보자. POST는 body message를 처리한다고 했다. 즉 GET과 달리 body message가 추가된다. 아래는 "만약 POST작업을 캐싱한다면"의 예시이다. 캐시는 key:value 구조를 가진다.

만약 url을 key로 사용한다면 body message가 달라질 경우 동일한 작업이 보장되지 않는다.

/api/submit: POST /api/submit {"username": "user1", "password": "pass1"}

/api/submit: POST /api/submit {"username": "user2", "password": "pass2"}

보통 HTTP 캐시는 요청을 구분하는 주요 키로 URL을 사용한다. POST 요청의 본문은 URL과는 별도로 고유한 캐시 키를 구성해야 하며, 이는 복잡성과 추가적인 관리를 필요로 한다.

즉 GET보다 POST가 다뤄야할 변수가 많기에 상태를 저장하는 것이 유리하지 않을 확률이 더 높다는 것이다. POST는 응답 메시지를 캐싱하기에도, 요청 메시지를 캐싱하기에도 난이도가 높아진다.


이해를 확인하기 위해 제가 작성한 캐시가능에 대한 설명입니다. 혹시 틀린점이 있을까요? 요청정보 캐싱과 응답정보 캐싱에 대한 제 설명이 확신이 서지 않습니다...