API의 ETag가 같으면 거래 파일을 다시 내려받지 않아도 되나

발행

거래 파일을 정기적으로 내려받는 도구에서 ETag를 저장하면 같은 자료를 불필요하게 다시 전송받는 일을 줄일 수 있다. 그러나 ETag가 같다는 이유만으로 모든 거래가 최신이고 행 하나도 바뀌지 않았다고 보고하면 범위를 넘는다. ETag는 서버가 선택한 HTTP 표현의 검증자이며, 업무 데이터 전체에 대한 감사 결과가 아니다.

RFC 9110은 저장한 ETag를 If-None-Match에 넣어 조건부 GET을 보내는 방식을 설명한다. 서버가 해당 조건을 평가해 저장된 표현과 일치한다고 판단하면 304 Not Modified로 응답할 수 있다. 이때 새 본문을 내려받는 대신 보존한 본문을 재사용한다. 따라서 로컬에 대응하는 원본 본문이 없는 상태에서 304만 받았다고 새 데이터셋을 구성할 수는 없다.

운영 메모에는 요청 URL, 필요한 질의 조건, 응답 상태, ETag, 대응하는 로컬 파일을 함께 기록한다. 예를 들어 특정 지역·월의 파일 A에 대한 태그를 다른 지역·월의 파일 B에 그대로 쓰면 동일한 자료를 검증한 것이 아니다. 단순히 태그 문자열이 비슷하다는 이유로 서로 다른 요청의 결과를 합치지 않는다. 인증이나 요청에 따라 표현이 달라지는 서비스라면 제공기관의 캐시 지침도 확인한다.

특히 W/ 표시가 있는 약한 ETag는 바이트가 완전히 동일하다는 보증으로 읽지 않는다. RFC는 If-None-Match에서 약한 비교를 사용하도록 하며, 캐시 재사용에 적합한 동등성과 모든 바이트의 동일성을 구별한다. 재현이 필요한 분석에서는 실제 보존 파일의 체크섬과 다운로드 이력도 별도로 관리할 수 있다.

304가 나와도 해당 API의 다음 페이지 누락이나 원자료의 신고 지연까지 검증되지는 않는다. ETag를 지원하지 않거나 서버의 갱신 정책이 명확하지 않으면 제공기관의 배포 설명을 확인하고 최신성 판단을 보류한다. 이 글은 읽기 전용 자료 수집의 전송 규칙을 설명한다. 쓰기 요청이나 운영 시스템 설정을 변경하는 절차가 아니며, 실제 서비스에 적용하기 전에는 해당 API가 명시한 사용·호출 조건을 따라야 한다.

출처와 확인일