HTTP QUERY 메서드

QUERY는 실질적인 공백을 메우는 제안 단계의 HTTP 메서드입니다. GET처럼 **안전(safe)**하고 **멱등(idempotent)**하면서, POST처럼 **요청 본문(body)**을 실어 나를 수 있습니다. *“페이로드를 보낼 수 있는 GET”*이라고 생각하면 됩니다.

왜 존재하는가

복잡한 질의는 오랫동안 어색한 양자택일을 강요해 왔습니다.

• **쿼리 문자열을 쓰는 GET**은 모든 필터를 URL에 담습니다. URL에는 길이 제한이 있고, 평문으로 로그에 남으며, 구조화되거나 중첩된 조건을 다루기에는 투박합니다.
• **본문을 쓰는 POST**는 페이로드는 잘 실어 나르지만 의도를 속입니다. POST는 안전하지도 멱등하지도 않으므로, 캐시와 크롤러와 중계자는 그 요청이 상태를 바꾼다고 가정해야 합니다. 실제로는 그렇지 않습니다 — 그저 읽고 있을 뿐입니다.

QUERY는 이 긴장을 해소합니다. 의미론은 *“이것은 읽기다”*라고 말하고, 본문이 조건을 실어 나릅니다.

특성

요청은 어떻게 생겼는가

QUERY /products HTTP/1.1
Host: shop.example
Content-Type: application/json
Accept: application/json

{ "category": "boots", "inStock": true }

Content-Location으로 캐싱하기

QUERY는 안전하고 멱등하므로 응답을 캐시할 수 있습니다 — 다만 본문이 달라지기 때문에 캐시 키를 URL만으로 삼을 수는 없습니다. 서버는 Content-Location 헤더로 결과의 정규 위치를 지정합니다.

HTTP/1.1 200 OK
Content-Location: /products?category=boots&inStock=true
Cache-Control: max-age=60

그러면 캐시(또는 클라이언트)는 동등한 요청에 대해 그 표현을 재사용할 수 있습니다. 바로 이것이 본문을 실어 나르는 읽기가 캐시 가능한 상태를 유지하게 해 주는 메커니즘입니다.

직접 해 보기

실시간 테스트로 가서 이 사이트의 에코 엔드포인트에 실제 QUERY 요청을 보내 보세요. 메서드와 헤더와 본문이 서버에 어떻게 도착하는지 정확히 확인할 수 있습니다.

QUERY는 IETF Internet-Draft에 정의되어 있으며 아직 발전하는 중입니다. 위의 내용은 작업용 요약으로 받아들이고, 권위 있는 최신 원문은 링크된 draft를 확인하세요.