Get메서드에서 바디를 쓰는 건 좋지 않은 아이디어(bad idea)이다.

HTTP/1.1이후부터는 GET메서드에서 BODY를사용할 수 있게 됐다.
HTTP스펙에서 GET메서드의 바디 사을 금지하진 않았지만, 이를 사용하는 건 표준적이지 않고 심지어 나쁜 결과로 이어질 수 있다.

GET 요청에 바디를 넣어서 보내더라도 서버는 이를 거부할 수도 있고, GET요청의 바디를 읽고 처리해야할 의무가 있는 것도 아니다.(반드시 해야 한다는 인식이 있다는 건 아니다)

왜 GET에서 바디를 쓰지 않는데?

그 이유는 다음과 같다.

• GET메서드의 원래 의미와 맞지 않다. GET는 데이터를 읽는 작업이다. 부수적인 효과를 유발하지 않아야 한다. 그런데, body를 포함한다는 건 일반적으로 서버에서 처리해야할 데이터를 전달한다는 것이다. 리소스를 생성하거나 변경하는 작업을 요청한다는 것인데, GET의 의미와 맞지 않는다.
• 일부 서버는 GET의 바디를 읽지 않고, 심지어 거절(reject)하기도 한다.
• cache와도 맞지 않는다. 바디는 보통 캐싱이 되지 않기 때문에, 캐싱과 관련된 작업을 혼란스럽게 할 수 있다. 프록시 서버들이 get요청의 바디를 읽지 않아서 캐싱이 제대로 되지 않을 수 있다.
  (get요청은 cacheable해야 한다. 바디속 정보가 있어야 요청 처리가 가능한 경우 바디를 읽지 않았을 때, 캐싱을 하면 다음번에 캐시 정보를 다시 쓸 수가 없다.)

• 서버에선 get 요청의 바디를 잘 처리하지 않아서, 혹시모를 보안의 위협이 생길수 있다.

REST의 목적은 모두가 이해하는 공통적인 표준을 만들어 사용하는 것이다. 그만큼, GET의 원래 목적과 맞지 않은 사용은 가급적이면 피하는 게 좋다.

추가로, RFC 7134에 따르면 cache의 기본 키는 url이다. 캐시는 http의 메타 데이터만 이해하면 되는데, 바디를 포함시켜버리면 복잡해진다.

GET 요청 본문에 의미를 부여하려면, 그 의미가 캐시 동작에 어떤 영향을 미치는지 정의해야 한다.GraphQL 같은 쿼리에서는 응답의 표현이 요청 본문에 달려있다. 그러면 두 요청 본문이 "같은지" 정의해야 한다. -공백이 중요한지? 콘텐츠 인코딩이 중요한지? 본문이 압축되었을 때는 어떻게 되는지? 등등 (나중에 오는 요청과 지금 캐싱하는 요청이 같은 요청인지를 판단하는 거과 관련된 이슈로 보인다)

그럼 어떻게 해야해?

그냥 post메서드를 사용하면 된다. 혹은 url을 인코딩하거나, 커스텀 헤더를 사용하면 된다.

참고자료

Using a Body With an HTTP Get Method Is Still a Bad Idea