API
HTTP 캐시 헤더를 API와 HTML에 똑같이 두지 않은 비교 메모
HTML과 JSON 응답에 같은 Cache-Control 값을 적용했다가 관리자 화면 갱신이 늦어진 경험을 바탕으로, 응답 성격별 캐시 기준을 비교합니다.
저장은 됐는데 화면은 어제 데이터였다
관리자에서 공개 상태를 바꾼 뒤 목록 API를 다시 열었는데 응답이 그대로였다. 브라우저 문제라고 생각해 강력 새로고침을 했지만, 응답 헤더의 max-age=3600이 원인이었다. 정적 HTML을 빠르게 만들려고 넣은 값을 관리용 JSON에도 복사한 실수였다.
같은 캐시라도 대상이 다르다
| 응답 | 우선한 기준 | 예시 |
|---|---|---|
| 버전이 있는 정적 파일 | 오래 보관 | public, max-age=31536000, immutable |
| 공개 HTML | 재검증 가능 | public, max-age=0, s-maxage=300 |
| 관리자 API | 최신 데이터 | private, no-store |
관리자 API는 다른 사람이 같은 기기에서 볼 가능성도 있어 private만으로는 부족했다. 저장 결과를 바로 보여야 하므로 아예 저장하지 않도록 했다.
응답마다 명시했다
return Response.json(post, {
headers: {
'Cache-Control': 'private, no-store',
},
});
공개 목록은 CDN 재검증을 허용하되 게시물 수정 직후에는 경로 무효화도 호출했다. 헤더 하나가 모든 화면에 맞을 것이라는 기대를 버리니 기준이 단순해졌다.
확인할 것
curl -I https://example.com/api/admin/posts
curl -I https://example.com/posts
- 로그인한 응답에
public이 붙지 않았는가 - 수정 직후 필요한 화면의 갱신 시간이 정해져 있는가
- 정적 자산 이름에 해시가 있는가
캐시는 성능 옵션이면서 데이터 노출과 최신성 정책이다. 이제는 값을 복사하기 전에 이 응답을 누가, 언제 다시 읽어도 되는지부터 적는다.