HTTP GET의 한계를 넘어서는 새로운 QUERY 메서드 등장
새로운 HTTP 메서드 QUERY(RFC 10008)가 제안되어 GET의 한계를 보완하려는 움직임이 있음
요청 본문(Request Body)을 포함한 캐싱 가능성이 논의되나, 실효성 및 복잡성에 대한 비판적 의견이 지배적임
멱등성(Idempotency) 보장으로 POST 폼 제출 시 새로고침 경고 회피 등 HTML 폼 지원 가능성이 언급됨
GET 메서드에 요청 본문을 포함하려는 과거 시도와 달리, 별도 메서드 분리로 HTTP 아키텍처 정의 준수를 시도함
QUERY 메서드의 캐싱 전략과 한계
커뮤니티에서는 QUERY 메서드가 요청 본문을 캐시 키(Cache Key)에 포함하는 방식에 대해 실효성 의문을 제기합니다. 특히 본문 내용에 따라 캐시 키가 무한정 커질 수 있으며, 이는 캐시 무효화(Cache Busting)를 용이하게 할 수 있다는 지적입니다. 또한, 이러한 방식은 데이터 격리 아키텍처(Data Isolation Architecture)를 고려할 때 HTTP 계층보다는 애플리케이션 레벨에서의 캐싱이 더 적합하다는 의견이 다수입니다.
GET vs QUERY: HTTP 아키텍처 정의 준수
GET 메서드에 요청 본문을 포함하려는 과거 시도와 달리, 이번 RFC는 별도의 QUERY 메서드를 분리했습니다. 이는 HTTP의 핵심 아키텍처 정의(Core Architectural Definitions)를 엄격히 준수하고 역사적 상호운용성 문제(Historical Interoperability Issues)를 피하기 위한 결정으로 보입니다. GET은 리소스 조회에 집중하고, QUERY는 복잡한 필터링이나 대용량 데이터 전송 등 특수 목적(Niche Use Case)을 위해 설계되었다는 설명입니다.
HTML 폼 지원 및 멱등성(Idempotency)의 이점
QUERY 메서드가 멱등성(Idempotency)을 요구한다는 점은 HTML 폼 제출 시 새로고침으로 인한 중복 제출 경고(Re-submission Warnings)를 피할 수 있다는 잠재적 이점을 시사합니다. 이는 사용자 경험 측면에서 긍정적일 수 있으며, 특히 POST 요청으로 인한 부작용 없이 상태 변경을 유발하지 않는(Non-State-Changing) 복잡한 쿼리를 안전하게 전송할 수 있다는 점에서 주목받고 있습니다.
대안으로 제시된 'Vary: request-body' 헤더
일부 개발자는 QUERY 메서드 대신 기존 POST 요청에 'Vary: request-body'와 같은 새로운 HTTP 헤더를 도입하는 것이 더 나은 대안이라고 주장합니다. 이 방식은 하위 호환성(Backwards Compatibility)을 유지하면서도, 필요한 경우에만 캐싱 전략을 적용할 수 있어 QUERY 메서드의 복잡성을 피할 수 있다는 것입니다. 이는 CDN과 같은 인프라에서 점진적인 채택(Progressive Adoption)을 가능하게 할 것이라는 의견입니다.
