13P by xguru 28일전 | favorite | 댓글 7개
  • 새로운 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  

이걸 왜 프로토콜에 추가해야 하는지 모르겠어요.
쿼리 매개변수가 수 KB를 넘기는 시나리오가 그렇게 많나요?

https://www.baeldung.com/cs/http-get-with-body
HTTP 스펙이 독자에게 자체 해석의 여지를 주고 일관성없이 변해서 아예 메소드를 새로 만드려는 걸로 보입니다

GET with request body

일부 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

https://elastic.co/guide/en/…

  1. 표준 스펙에서 GET Method 는 body 에 대한 부분을 명시하지 않았지, 넣지 말라고 한적은 없습니다

  2. 서버 프레임워크에서 GET Method 에서 body를 처리하지 않는 경우가 있어서 MDN 에서는 GET Method 에 body 를 넣지 말라고 권장하고 있습니다

  3. Elasticsearch 는 GET Method 에서 Body를 지원합니다

라이브러리 구현에 의해서 스펙이 변경되야하는건 더 많은 고민이 필요하지 않을까싶네요