The HTTP Query Method
(ietf.org)- 새로운 HTTP 메소드인 QUERY를 제안
- Request시에 콘텐츠를 전달할 수 있는, 안전하고 멱등성(idempotent)이 있는 요청 메소드
- Request에 전달되는 데이터가 너무 커서 URI로 인코딩할 수 없을 때 이 방법을 사용가능
- 쿼리 매개변수가 수KB 이상일 경우 많은 구현체에서 제한을 둠
- 요청 전에 이 제한을 미리 알수 없는 경우가 많고, 인코딩 해야하므로 비효율적
- 그래서 많은 구현에서는 GET 대신 POST를 사용하여 쿼리를 수행
- 하지만 서버에 대한 구체적인 지식이 없으면, 안전하고 멱등성이 있는지 등을 알 수 없어서 GET과 동일한 기본적 제한이 있음
- QUERY 메소드는 GET과 POST 사용 간의 격차를 해소하는 솔루션을 제공
- POST와 마찬가지로 쿼리 작업에 대한 입력은 요청 URI의 일부가 아닌 요청의 컨텐츠 내에서 전달
- 그러나 POST와 달리 이 메소드는 명시적으로 안전하고 멱등성이 있어, 캐싱 및 자동 재시도와 같은 기능을 할 수 있음
Request
QUERY /contacts HTTP/1.1
Host: example.org
Content-Type: example/query
Accept: text/csv
select surname, givenname, email limit 10
Response
HTTP/1.1 200 OK
Content-Type: text/csv
Content-Location: /contacts/responses/42
Location: /contacts/queries/17
surname, givenname, email
Smith, John, john.smith@example.org
Jones, Sally, sally.jones@example.com
Dubois, Camille, camille.dubois@example.net
https://www.baeldung.com/cs/http-get-with-body
HTTP 스펙이 독자에게 자체 해석의 여지를 주고 일관성없이 변해서 아예 메소드를 새로 만드려는 걸로 보입니다
일부 client library 에는 GET 을 요청할때 아예 request body 를 전달하는 방법이 없는데, 그 대안이 될 수 있을 것 같네요
라이브러리 구현체의 관점에서 본다면 오히려 더 필요없는 표준 변경 제안이 아닐까요?
표준 스펙상 GET은 리퀘스트 바디를 가질 수 없는데, 라이브러리가 임의로 리퀘스트 바디를 넘기는거니...
그럴거면 그냥 라이브러리 단에서 커스텀 메서드를 구현해도 무방한게 아닐까요?
필요성을 아예 부정하긴 힘들지만, HTTP 1.0에서 1.1로 올라가며 생긴 PUT, PATCH, DELETE 등에 비해 설득력이 떨어지는 것 같습니다.
https://www.rfc-editor.org/rfc/rfc9110.html#name-method-definitions
https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/GET
https://stackoverflow.com/questions/978061/http-get-with-request-body
-
표준 스펙에서 GET Method 는 body 에 대한 부분을 명시하지 않았지, 넣지 말라고 한적은 없습니다
-
서버 프레임워크에서 GET Method 에서 body를 처리하지 않는 경우가 있어서 MDN 에서는 GET Method 에 body 를 넣지 말라고 권장하고 있습니다
-
Elasticsearch 는 GET Method 에서 Body를 지원합니다