[API] API 캐싱(caching)

캐시 가능성은 API 통신 간 자주 호출되는 데이터를 캐시 메모리에 별도로 저장하는 것으로, REST API의 조건 중 하나입니다.

API 캐싱은 요청/응답의 header에 명시된 정보를 통해 그 여부를 판단할 수 있습니다.

1. Cache-Control header

Cache-Control header의 max-age값은 해당 자원이 캐싱될 경우, 얼마나 유효한지를 초 단위로 나타냅니다.

예를 들어, max-age=60일 때는 응답의 자원이 캐시 된 후 60초 내로 동일한 자원을 요청하면 캐시에 보관된 데이터를 바로 사용할 수 있습니다. 60초 이후 새로운 요청이 있다면, 응답할 때 자원은 다시 캐시됩니다.

client >>> 
GET /members/1/profile

server <<<
200 OK
Content-Type: image/png
Cache-Control: max-age=60

2. Last-Modified header

캐시된 자원이 만료되었더라도 그 값이 수정되지는 않았을 수 있습니다. 이 경우는 굳이 새로 캐시할 필요가 없습니다.

Last-Modified header를 사용하면 해당 자원이 언제 마지막으로 수정되었는지를 확인할 수 있습니다.

 

클라이언트가 요청을 보낼 때 캐시에 Last-Modified 값이 있다면,

해당 값을 If-Modified-Since header에 포함하여 전달합니다.

 

만약 이 값이 서버가 가진 자원의 Last-Modified 값와 일치한다면,

304 Not Modified 상태코드와 함께 헤더만 요청으로 전송합니다.

 

이는 캐시 메모리에 있는 헤더에 갱신되고, 클라이언트는 캐시 메모리의 데이터값을 계속 사용할 수 있습니다.

client >>> 
GET /members/1/profile
If-Modified-Since:
    Mon, 25 Dec 2023 00:00:00 GMT

server <<<
304 Not Modified
Content-Type: image/png
Cache-Control: max-age=60
Last-Modified: Mon, 25 Dec 2023 00:00:00 GMT

3. ETag header

Last-Modified header는 시간의 형식으로 정보를 저장하기 때문에, 1초 이하의 단위로 캐시 관리를 하지 못합니다.

또한, 실질적으로 바뀐 내용은 없고 수정 시간만 변경된 경우도 따로 구분하지 못한다는 문제도 있습니다.

 

이를 위해 ETag를 사용할 수 있습니다.ETag(Entity Tag)는 자원 고유의 식별자이며, 자원의 내용이 바뀌면 ETag 또한 변경됩니다.

 

클라이언트가 요청을 보낼 때 캐시에 ETag 값이 있다면,

해당 값을 If-None-Match header에 포함하여 전달합니다.

 

만약 이 값이 서버가 가진 자원의 Last-Modified 값와 일치한다면,

304 Not Modified 상태코드와 함께 헤더만 요청으로 전송합니다.

 

이는 캐시 메모리에 있는 헤더에 갱신되고, 클라이언트는 캐시 메모리의 데이터값을 계속 사용할 수 있습니다.

client >>> 
GET /members/1/profile
If-None-Match:
    "33a64df551425fcc55e4"

server <<<
304 Not Modified
Content-Type: image/png
Cache-Control: max-age=60
ETag: "33a64df551425fcc55e4"

 

이 세 가지 헤더들은 독립적으로 사용되는 것이 아닌, 상황에 맞춰 서로를 보완하며 사용됩니다.

상황에 맞는 적절한 캐시를 사용하면 불필요한 요청에 대한 응답을 발생하지 않게 할 수 있습니다.