[HTTP] GET vs POST, GET은 body 값을 가지면 안 될까?

🌱 들어가기 전

스터디를 진행하면서, GET 요청과 POST 요청의 차이가 단순히 '의미론적'으로만 차이가 있는 건지 궁금해서 찾아보게 되었다.
습관적으로 나는 리소스 등록 시 POST를, 그리고 조회 시 GET을 사용했었다.
하지만 리소스 등록 시에도 GET을 사용하는 것이 문법적으로도 안 되는 건지, 아니면 관습적으로 사용하지 않는 것인지는 궁금해서 찾아보았다. 그리고 몇 가지 요청들을 실습해가며 어느 정도 생각을 정리해두었다.
(영어 원문에 대한 번역을 하다 보니 다소 의미적 차이가 있을 수도 있습니다 🥲)

 

---

✔️ GET

The GET method requests that the target resource transfer a representation of its state.
GET requests should only retrieve data and should have no other effect.

GET 메서드는 타겟 리소스가 해당 리소스의 상태를 표현하는 것을 전송하도록 요청하는 것이다.
GET 요청은 데이터를 검색해야 하며, 다른 부수적 효과가 나타나지 않도록 해야 한다.
 
여기서 'retrieve data'라는 표현이 쓰였는데, 이는 DBMS에서 데이터를 가져오는 것을 의미한다.
= 데이터를 어떠한 쿼리를 통해서 가져오는 행위를 의미한다.
 
리소스의 변경 없이 검색을 할 때는 URL을 통해 '검색'하는 GET 요청이 더 유용하다.
W3C (국제 웹 표준 기구)에서는 다음과 같이 GET을 정의하였다.

Use GET if:
The interaction is more like a question. (i.e, it is a safe operation such as a query, read operation, or lookup)

만약 '질문하는 것처럼' 어떠한 것을 물어볼 때, read 연산을 할 때 GET을 사용하라고 하였다.
그리고, URI을 이용해서 정보를 요청하라고 말하고 있다.
 
기본적으로 웹 아키텍처는 RFC2396에 의해 정의된 URI로 시작된다. Web은 Web끼리 서로 참조하고, 설명하고, 접근하고, 공유할 수 있도록 URI의 규칙을 따르게 되는데, 리소스에 대한 URI는 linking, bookmarking, caching 등 다양한 이점을 준다고 소개한다.
여기서 'URI addressability'라는 단어를 소개하는데, 이는 클라이언트가 특정 타입의 상호작용을 수행하기 위해서는 URI로도 충분하다고 말한다. 즉, URI만으로도 통신하기 충분하다는 의견이다. (물론, 나는 동의하지 않는다 😅)
 

By convention, when GET method is used, all information required to identify the resource is encoded in the URI

또한, HTTP/1.1에서 GET은 검색 이외의 동작을 수행하도록 하지 않는 것이 좋다고 소개하고 있다.
애초에 GET 요청 자체를 '안전한 메서드'라고 판단하는데, 자원을 단순히 읽기만 하는 것이기 때문에 서버에 영향을 끼치지 않기 때문이다.
하지만, GET 요청의 경우 결과적으로 필요한 모든 정보가 URI에 들어가기 때문에, 보안적인 측면에서 생각해보았을 때 body에서 데이터를 제공하도록 'GET with BODY'라는 것이 논의되기는 했었는데 기각되었다고 한다. (물론 과거다)
 
그래서 이에 대해서 또 여러 가지를 찾아보았다.
로이 필딩이라는 사람은 'GET with BODY'에 대해서 다음과 같은 의견을 남겼다.

Yes. In other words, any HTTP request message is allowed to contain a message body, and thus must parse messages with that in mind. Server semantics for GET, however, are restricted such that a body, if any, has no semantic meaning to the request. The requirements on parsing are separate from the requirements on method semantics.

So, yes, you can send a body with GET, and no, it is never useful to do so.
This is part of the layered design of HTTP/1.1 that will become clear again once the spec is partitioned (work in progress).

모든 HTTP 요청 메시지는 기본적으로 message body가 포함될 수 있다.
하지만, 'GET'에 대해 의미론적인 관점으로 보았을 때, body가 있는 경우 요청에 대해서 별다른 의미가 없도록 제한된다.
그래서 GET으로 body를 담아 보낼 수는 있지만, 사실상 좋지 않은 설계라고 말했다. (HTTP/1.1 기준)
 
실제로, HTTP/1.1 spec에 가면 다음과 같이 정의되어 있다.

The GET method means retrieve whatever information ([...]) is identified by the Request-URI

결과적으로 GET 메서드는 Request-URI를 통해 식별되는 정보를 검색하는 것을 의미한다는 것이다.
 
하지만, 2014년부터 HTTP/1.1의 기본 스펙이었던 RFC2616이 제거되고, RFC 7230-7237로 대체되엇다.
기존에 존재하던 "the message-body SHOULD be ignored when handling the request" 라는 문구가 제거되고, 다음과 같은 문구가 추가되었다.

🌱 Request message framing is independent of method semantics, even if the method doesn't define any use for a message body.

요청 메시지에 대한 프레임은 이제 method의 의미론적 관점과 독립적이며, 해당 메서드가 message body에 대해 정의하지 않더라도 상관없다라고 나와 있다. 또한 앞서 언급했던 The GET method means retrieve whatever information ([...]) is identified by the Request-URI 에 대한 부분도 제거되었기 때문에, 결과적으로 생각해본다면 의미론적 관점에서 보았을 때도 GET 요청에 request body가 들어가도 상관이 없다는 것이다.
 
하지만, 상관은 없다만 body가 특별한 의미를 가지는 것은 아니다. RFC7231에서는 다음과 같이 정의되어 있다.

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 요청의 request message에는 정의된 의미가 없기 때문에, GET 요청에 body를 넣었을 경우 기존의 구현체에서는 요청을 거부할 수도 있다는 것이다.
 
실제로 ES에서는 GET 요청에서 body를 활용하는 경우도 있다.

여기서도 마찬가지로 RFC 7231의 내용을 언급하며, GET with body를 통해 검색하는 것을 선호한다고 했다 😀
 
그래서 결과적으로 나는 이렇게 결론 내렸다.
body에 넣을 수는 있고, 이게 정의된 사항에서는 위반되는 것이 아니다.
다만, 기존에는 금지가 되었던 게 일반적이기 때문에 기존 구현체들의 경우 body를 담아 GET을 보내면 거절당할 수가 있기 때문에 신중하게 사용할 필요가 있다. (또한, 통상적으로 사람들이 생각하는 관념이 있기 때문에 웬만하면 리소스의 요청으로만 사용하려고 한다)
 

---

✔️ POST

The POST method requests that the target resource process the representation enclosed in the request according to the semantics of the target resource. 

POST는 타겟 리소스가 요청에 표현된 것을 타겟 리소스의 의미에 따라서 처리하는 것을 의미한다.
 
RFC7231에서는 다음과 같은 상황에서 사용하라고 말한다.
1. HTML form에 입력한 필드의 값들에 대한 데이터를 제공할 때
2. 게시판, 메일링, 블로그 같은 글 관련 메시지를 작성할 때
3. origin 서버에서 식별되지 않은 새로운 리소스를 생성하는 경우
4. 이미 존재하는 리소스에 대해서 덧붙일 때 
 
잘 생각해보면, 모두 다 '데이터를 전송한다'라는 관점에서 사용할 수 있다.
POST 방식의 경우 request body 값에 데이터를 넣어서 보내는 것이 일반적이다.
 
하지만, POST 방식이더라도 데이터 검색에서 사용할 수 있다.
검색 조건이 매우 까다로워서 URL에 붙여질 데이터가 많아질 경우, POST를 고려할 수 있다.
기본적으로 브라우저는 처리할 수 있는 URL의 길이가 제한이 있으며, 보통 파라미터로 넘어간 값들은 인코딩 시 글자수가 더 늘어나기 때문에 더 주의해야 한다. Apache HTTP 서버는 최대 4000자, Microsoft Internet Explorer는 최대 2048자를 처리할 수 있다.
 
또한, 사용자의 이름이나 비밀번호 같은 정보 같이 민감한 정보는 URL로 보내지 않는 것이 좋다. 
HTTPS를 사용하더라도 브라우저 기록이나 웹 서버 로그에 전체 URL이 포함될 수 있기 때문에 이런 경우 보통 POST를 사용한다.
(단, URL에 데이터가 노출되지 않음으로 보안성은 증가하지만 캐싱은 되지 않는다는 것이 특징이다)
 

---

✔️ GET with URI

🌱 GET - query Parameter

만약 GET 통해 리소스를 등록하고 싶다면 쿼리 파라미터를 활용할 수 있다.
실습을 위해 간단한 html을 구성하였다.

그냥 이름이랑 나이 넣고 제출할 수 있는 form이다.

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>Title</title>
</head>
<body>

<form action="/test" method="get">
    이름: <label>
    <input type="text" name="name"/>
</label>
    나이: <label>
    <input type="text" name="age"/>
</label>
    제출하기: <input type="submit", value="submit">
</form>
</body>
</html>

 
그리고, 이에 대응하는 컨트롤러를 만들어보자.

@RestController
public class Controller {

    @GetMapping("/test")
    public void test(@RequestParam("name") String name, @RequestParam("age") int age) {
        System.out.println("name = " + name);
        System.out.println("age = " + age);
    }
}

정말 간단한 컨트롤러이다.
이제 요청을 날려보자. 어떤 식으로 동작하게 될까?

submit을 누르면 위와 같이 name과 age라는 쿼리 파라미터가 붙은 것을 확인할 수 있다.

또한, 값에 대한 바인딩 역시 잘 된 것을 볼 수 있다.
 
 

---

🌱 POST - query parameter

만약, Post로 요청을 바꾸면 어떻게 될까?
html 파일의 method 부분을 post로 바꾸고, 컨트롤러 역시 @PostMapping을 활용하도록 바꾸어보자.

@PostMapping("/test")
public void test(@RequestParam("name") String name, @RequestParam("age") int age) {
    System.out.println("name = " + name);
    System.out.println("age = " + age);
}

이번에는 제출하더라도 별다른 쿼리 파라미터가 붙지 않게 된다.

하지만 값에 대한 바인딩의 경우 잘 되는 것을 확인할 수 있다. 이 값들은 어디에 저장된 걸까?

우선, request의 content-type을 보면 x-www-form-urlencoded 타입으로 지정된 것을 볼 수 있다.

그리고 페이로드를 보면 위와 같이 form data로 설정된 것을 확인할 수 있다!
application/x-www-form-urlencoded의 경우 POST 요청으로 쿼리 파라미터를 사용할 때 전송되는 타입이라고 볼 수 있다.
그렇다고 해서 쿼리 파라미터로 보내는 것과 동일한 것은 아니다. 
단지, body 값의 요청으로 넣을 때 content-type이 application/x-www-form-urlencoded인 것뿐이다.

실제로 스니펫 같은 경우도 위와 같이 body 값에 key-value 형식으로 전송된다. 😀
즉, POST로도 request parameter를 통해 데이터를 전달할 수 있다는 것이 확인되었다.
 

---

🌱 POST - multipart/form-data

하지만 아까 form 태그를 활용했을 때는 multipart/form-data로 값이 넘어갔었다. 
그러면 multipart/form-data로 보낸 요청은 @RequestParam으로 받을 수 있다는 것일까?

궁금하기 때문에 바로 해보았다.

오... 바인딩이 매우 잘 된다! body 값으로 담긴 multipart/form-data도 @RequestParam으로 받을 수 있다는 사실을 깨달았다.
실제로 공식 문서를 가보니까, @RequestParam에 다음과 같이 작성되어 있었다.
 

In Spring MVC, "request parameters" map to query parameters, form data, and parts in multipart requests. This is because the Servlet API combines query parameters and form data into a single map called "parameters", and that includes automatic parsing of the request body.

Spring MVC에서 말하는 web request parameter란, 쿼리 파라미터와, form-data, multipart request에서 각각의 part 데이터들이 매핑된다고 한다. 이유는? 서블릿 API가 쿼리 파라미터와 form data를 "parameters"라고 불리는 단일 map으로 결합하고, request body의 자동 구문 분석을 포함하기 때문이다! (이 부분은 처음 알아서 엄청 놀랐다.)

---

 

🌱 POST - query parameter with form data

그렇다면, form data와 쿼리 파라미터를 동시에 넣으면 어떻게 요청이 올까? 이것도 궁금해서 실험해보았다.
 
1. form data와 query parameter로 받는 값의 이름이 다를 때

위와 같이 요청을 보내보았다.

바인딩도 매우 잘 되었다. 그렇다면, GET 요청으로 보냈을 때는 어떻게 나올까?

당연히 되지 않는다. GET 요청에서는 name, age, name2, age2 모두 다 쿼리 파라미터로 들어오기를 예상하고 있기 때문이다.
 
 
2. form data와 query parameter로 받는 값의 이름이 같을 때

요청을 한 번 날려보자.

굉장히 신기한 결과가 나왔다! name의 경우 ,으로 구분된 결과가 나왔지만, age의 경우 파라미터로 넘긴 값만 들어갔기 때문이다.
왜인지 궁금해서 까보려고 했는데, 이거는 코드 레벨로 들어가야 할 것 같아서 우선 다음 포스팅에서 알아보고자 한다.
 
만약 GET으로 요청한다면 어떻게 될까?
 

body에 들어있는 값은 무시되고, 쿼리 파라미터의 값만 받는다.
 

---

🌱 파일 업로드와 request parameter

그렇다면, 파일 업로드 기능을 하기 위해 form tag를 사용한다면 정상적으로 요청이 갈까?

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>Title</title>
</head>
<body>

<form action="/test" method="post">
    파일: <input type="file" name="file">
    제출하기: <input type="submit" value="submit">
</form>
</body>
</html>

아까와 비슷하지만 매우 심플한 파일 업로드 html을 만들었다.

@RestController
public class Controller {

    @PostMapping("/test")
    public void test(@RequestParam("file") MultipartFile file) {
        System.out.println(file.getOriginalFilename());
    }
}

Get 요청을 통해서 파일을 받아보자.

파일 업로드 시 다음과 같은 오류가 발생한다. 파일의 경우 GET 요청으로 받을 수 없는 것이다.
 
POST로 변경해보자.

같은 이미지 아님

여전히 오류가 발생한다.
앞서 말했던 것처럼, POST에서 @requestParam을 쓸 경우 application/x-www-form-urlencoded 방식으로 받는다.
하지만 파일 같은 바이너리 데이터를 우리가 인코딩할 수 있을까? 아니다.
 

The content type "application/x-www-form-urlencoded" is inefficient for sending large quantities of binary data or text containing non-ASCII characters. The content type "multipart/form-data" should be used for submitting forms that contain files, non-ASCII data, and binary data.

애초에 W3C에 따르면 application/x-www-form-urlencoded의 경우, 간단한 텍스트나 ASCII 형식으로 데이터를 보내는 것이라고 정의했기 때문이다. 대형 바이너리 값의 경우 사용이 불가능하다.
 
그래서 파일 업로드 시 받고 싶다면 multipart/form-data를 활용해야 한다.

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>Title</title>
</head>
<body>

<form action="/test" method="post" enctype="multipart/form-data">
    파일: <input type="file" name="file">
    제출하기: <input type="submit" value="submit">
</form>
</body>
</html>

form 태그의 enctype에서 multipart/form-data로 변경하자.

그리고 다시 요청을 보내면 위와 같이 원본 파일명이 잘 뜨는 것을 볼 수 있다.
 

실제로 Request Header의 값을 보더라도 multipart/form-data 형태로 잘 전달되는 것을 볼 수 있다.
 

@RestController
public class Controller {
    @PostMapping("/test")
    public void test(@RequestBody MultipartFile file) {
        System.out.println(file.getOriginalFilename());
    }
    
    // @PostMapping("/test")
    public void test(@RequestPart MultipartFile file) {
        System.out.println(file.getOriginalFilename());
    }
}

@RequestParam이 아니더라도 @RequestBody, @RequestPart를 활용하여 multipart/form-data 형태의 데이터를 받을 수 있다.