[REST API] REST 제약조건_캐싱(Caching)

캐시가 사용 가능해야 한다는 것은 REST의 6가지 제약조건 중 한 가지입니다. 캐싱이 어떤 것인지는 저의 예전 포스터를 참고 부탁드립니다.

캐시관련 http Method

• GET - 일반적으로 브라우저에서 cache가 사용 가능하게 처리합니다.
• POST - 일반적으로 cache가 사용 불가능합니다. 하지만 Expires와 Cache-Control header를 이용하여 caching을 구현하여 응답할 수 있습니다.
• PUT, DELETE - 해당 REQUEST는 Cache를 적용할 수 없습니다.

cache관련 http 헤더

Expires

리소스의 cache 만료 시간을 절대값으로 나타낸 것입니다. 해당 헤더의 시간이 지나면 캐시가 아닌 원래 서버에 요청을 하여 리소스를 다시 얻어와야 합니다.

Expires: Fri, 20 May 2019 19:20:49 IST

Cache-Control

cache-control은 http 1.1에 추가된 헤더입니다. 해당 헤더는 캐시에 대한 다양한 조작을 가능하게 합니다. Cache-Control 헤더에도 리소스의 캐시 만료시간을 적용할 수 있는데 max-age를 이용하면 됩니다. Expires가 있는데 max-age가 또 나온이유는 Expires는 절대시간이기 때문입니다. 시스템별로 시간적인 차이가 있을 수 있어 리소스가 생성된 시간부터의 상대적인 시간 개념으로 max-age가 탄생하였습니다. max-age의 단위는 초입니다.

Cache-Control: max-age=3600

ETag

ETag는 리소스를 특정 문자열로 변경시킨 값입니다.(일반적으로 MD5 해싱을 이용) 리소스가 만약 변경되면 이 값도 변경되게 되어 cache 적용이 해제됩니다.

ETag: "abcd1234567n34jv"

Client에서는 ETag를 체크를 하기 위해 아래와 같은 헤더를 보냅니다. 이러한 캐시를 확인하기 위한 용도의 헤더를 조건부 헤더라고 부릅니다. 그러면 서버에서는 해당 헤더를 보고 etag가 동일하다면 cache 하라고304(Not Modified)를 던지며, 그렇지 않다면 정상응답으로200과 리소스를 반환합니다. (이는 사설 캐시를 이용할 경우, 캐시에 관련된 내용은 [HTTP] HTTP Cache - 프로세스와 기본 헤더에서 좀 더 자세하게 다룹니다.)

If-None-Match "abcd1234567n34jv"

Last-Modified

해당 리소스가 언제 마지막으로 변경되었는지 나타냅니다. Last-Modified 값은 응답 메시지가 제일 처음 생성된 Date날짜보다 빠를 수 없습니다.

Last-Modified: Fri, 10 May 2019 09:17:49 IST

클라이언트에서는 캐시체크를 하기 아래와 같은 헤더를 보냅니다. 그러면 서버에서는 해당 헤더를 보고 Last-Modified가 If-Modified-Since보다 값이 작다면 캐시를 사용하라고 304응답코드를 던지며, 그렇지 않다면 정상응답으로 200과 리소스를 반환합니다.

If-Modified-Since "Fri, 10 May 2019 09:17:49 IST"

마무리

이렇게 오늘은 캐시에 대해서 알아보았습니다. 다음 시간에는 REST API의 마지막 시간은 Security에 대해서 알아보도록 하겠습니다.

참조

https://restfulapi.net/caching/

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers