REST 아키텍처 스타일과 캐싱
Source
Evernote/Technote scraps/REST Architectural Styles and the Cache - The Carbon Shaft - Planet JBoss Community.md
Summary
이 문서는 REST 아키텍처 스타일의 핵심 제약 조건 중 하나인 ‘캐시(Cache)‘에 대한 HTTP 구현 요건을 설명합니다. 캐시 유효성 검증을 위해 ETag(강력/약한 검증자)와 Last-Modified 헤더를 사용하며, ETag가 우선적으로 권장됩니다. 조건부 GET(Conditional GET) 요청을 통해 If-Match, If-None-Match, If-Modified-Since 등의 헤더를 활용하여 서버와 클라이언트 간 불필요한 데이터 전송을 줄이고, 변경되지 않은 리소스에 대해서는 304(Not Modified) 상태 코드를 반환하여 네트워크 효율성을 높입니다. 또한, 캐시 만료 관리는 Expires 및 Cache-Control 헤더를 통해 이루어지며, Amazon S3와 같은 REST API 기반 서비스의 관리 콘솔 성능 향상에 캐싱이 핵심적인 역할을 함을 예시로 들었습니다.
Key Points
- REST의 6가지 제약 조건 중 ‘캐시’는 HTTP 캐싱 제약 조건을 준수해야 합니다.
- 캐시 검증자(Validator)로는 ETag와 Last-Modified가 있으며, ETag(특히 Strong ETag)가 더 신뢰할 수 있어 우선 사용해야 합니다.
- 조건부 GET(Conditional GET)은 If-Match, If-None-Match, If-Modified-Since, If-Unmodified-Since 헤더를 사용하여 리소스 변경 여부를 확인합니다.
- 검증자가 일치하면 서버는 304(Not Modified)를 반환하여 본문 전송을 생략하고, 불일치 시 412(Precondition Failed) 또는 200(OK)을 반환합니다.
- 조건부 HEAD(Conditional HEAD)는 조건부 GET과 동일하지만 응답 본문(body)을 반환하지 않습니다.
- 캐시 만료(Expiration)는 Expires 및 Cache-Control 헤더로 관리되며, 이는 REST 서비스 범위 외부의 캐시 소프트웨어 내부 로직입니다.
- REST API 기반 관리 콘솔의 경우, 캐싱과 조건부 요청을 활용하여 네트워크 오버헤드를 줄이고 응답 속도를 크게 향상시킬 수 있습니다.