HTTP QUERY는 GET과 POST 사이의 빈칸을 메운다. 문제는 메서드가 아니라 캐시 키다. HTTP QUERY를 이야기할 때 RFC 10008, API 캐싱, 보안 사고를 떼어 놓기 어렵다. QUERY는 본문을 가진 안전한 읽기 요청이다. 검색, 필터, GraphQL류 조회처럼 URL에 다 넣기 어려운 입력을 POST로 우회하던 관행을 정리한다. 개발자 커뮤니티에서 말이 붙는 이유도 분명하다. “GET with body가 드디어 표준화됐다”는 기대와 “공유 캐시가 이걸 제대로 처리하겠느냐”는 불신이 부딪힌다. QUERY는 읽기 API 설계를 깔끔하게 만든다. 동시에 캐시 구현이 틀리면 사용자 A의 응답이 사용자 B에게 갈 수 있다. ...
HTTP QUERY method(RFC 10008)는 GET과 POST 사이의 빈칸을 메운다. 그렇다고 지금 모든 검색 API를 QUERY로 바꿀 이유는 없다. 이 메서드가 건드리는 것은 라우터보다 캐시 키, 재시도, 로그, WAF, CORS, 관측성의 합의에 가깝다. 본문이 있는 안전한 조회는 작은 약속이다. 그 약속을 중간 계층 전체가 같은 방식으로 지키게 만드는 일은 크다. HTTP QUERY method는 왜 GET body 논쟁을 끝내지 못하나 RFC 10008은 2026년 6월 IETF Proposed Standard로 발행됐다. 핵심은 단순하다. QUERY는 요청 본문(request content)을 받아 서버 쪽 조회를 실행하지만, 메서드 의미는 안전(safe)하고 멱등(idempotent)하다. 연결이 끊겨 클라이언트나 프록시가 같은 요청을 다시 보내도 상태 변경이 중복 실행되지 않아야 한다. ...