HTTP GET method with payload body

HTTP GET method와 Body 값을 같이 사용할 수 있는 지 리서치한 내용입니다

Postman과 cURL에서 당연히 사용할 수 있어서 의심없이 사용하다가

안드로이드에서 기본 통신 라이브러리를 빌드했을 때 GET with body 요청을 보내면 POST with body로 변경되는 것으로 생각됐습니다 (서버 쪽에 로그를 보면 되는데 그 때 요청 로그를 지금 확인하기 힘들어서 추측만 하고 있습니다)

 

그래서 이번에 HTTP GET with payload bod에 대해 리서치 했습니다

 

 

GET with body에 토론한 것들 중에 가장 눈여겨볼 topic 입니다

https://stackoverflow.com/questions/978061/http-get-with-request-body/983458#983458

HTTP GET with request body

내용 본문과 comments를 보면 2014년에 RFC 내용이 변경되었음을 알 수 있습니다

 

본문 내용에서도 언급하고 있는 RFC 7231 (현재 최신 문서) 본문 내용 중 아래 내용이 가장 헷갈렸습니다

A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some existing implementations to reject the request.

GET 요청 내에 있는 payload는 정의된 의미론이 없습니다. GET 요청에 payload body를 보내는 것은 기존에 구현된 (애플리케이션)에는 요청이 거절될 수 있습니다.

정도로 번역할 수 있습니다. 저는 이 문장을 읽고 기존에는 GET with payload body가 허용이 되지 않았고 현재는 허용된다라는 의미로 이해했습니다

 

된다 안된다라는 내용이 아니라서 헷갈렸습니다 의역일 수도 있어서 밑에 있는 comments도 다 읽어보았습니다. 'Alessandro C'분께서 저랑 같은 의견이셔서 올바르게 이해했다고 생각했습니다

 

wikipedia HTTP (HyperText Transfer Protocol)

https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol#Request_methods

Hypertext Transfer Protocol - Wikipedia

 

wikipedia에서도 GET 요청에 payload body를 사용할 수 있다고 명시되어있습니다

 

 

추가로 GET 요청에 payload body를 사용할 수 없었던 때에는 어떻게 이 제약을 어떻게 대처했을 지 궁금했습니다

stackoverflow comment 중에서 dropbox의 글을 확인할 수 있었습니다

https://dropbox.tech/developers/limitations-of-the-get-method-in-http

Limitations of the GET method in HTTP

 

[dropbox tech 블로그 간략한 내용]

dropbox에서 HTTP 리소스 스펙 존중하면서 API 설계를 했습니다

 

While the HTTP standard doesn't define a limit for how long URLs or headers can be, most
HTTP clients and servers have a practical limit somewhere between 2 kB and 8 kB.

dropbox에서 /delta 라는 API를 만들 때 URL 길이가 길어지는 문제가 있었다고 합니다. URL 길이 제약이 공식 스펙에는 없지만 HTTP client들은 2~8 kB 제약을 두고 있었습니다.

 

As a rule, HTTP GET requests should not modify server state. This rule is useful because it lets intermediaries infer something about the request just by looking at the HTTP method.

For example, a browser doesn't know exactly what a particular HTML form does, but if the form is submitted via HTTP GET, the browser knows it's safe to automatically retry the submission if there's a network error. For forms that use HTTP POST, it may not be safe to retry so the browser asks the user for confirmation first.HTTP

intermediary(메시지 전달자, 브라우저나 요청을 전달하는 애플리케이션 등)가 HTTP method를 보고 네트워크 에러가 발생했을 때 어떻게 처리할 지 추론해서 처리하는 게 다릅니다

 

예전에는 GET에 body를 안 썼기 때문에 이 문제를 dropbox에서는 POST를 사용하여 문제를 해결하였습니다. POST를 사용하여 문제를 해결한 이유는 드랍박스에 아래와 같이 밝히고 있습니다

(저는 개인적으로 문제 해결의 판단 이유가 가장 중요하다고 생각합니다.)

 

We could have somehow contorted /delta to mesh better with the HTTP worldview, but there are other things to consider when designing an API, like performance, simplicity, and developer ergonomics.

HTTP의 발전에는 반대되지만, API 설계, 명료함, 개발자의 편의성을 위해서 POST with payload body를 사용해서 문제를 풀었다고 합니다.

 

결론

HTTP GET with payload body는 RFC 7231 스펙에 공식적으로 명시하고 있습니다

 

additional refer

https://datatracker.ietf.org/doc/html/rfc7231#section-4.3.1

rfc7231