클라이언트 개발자로서 GET과 POST에 대해서 알아야 할 것

며칠 전 코드 리뷰 중 이미지 검색 결과 조회의 HTTP Request의 메소드에 POST가 추가된 것을 보았다.

코드 작성자에게 이유를 물어보았더니 조회 요청에 필요한 파라미터(여기서는 이미지 안에 있는 오브젝트들의 좌표와 크기들)가 많이 늘어나서 서버 개발자가 POST 방식을 추가해달라고 했다고 한다.

요청 파라미터가 늘어나면 POST 방식을 사용해야 하는걸까?

우선 GET, POST의 기본적인 차이부터 알아보자.

GET — Requests data from a specified resource

POST — Submits data to be processed to a specified resource

GET은 요청이고 POST는 제출이다. 그리고 GET은 멱등이고 POST는 멱등이 아니다. (멱등은 연산을 몇 번하더라도 결과가 달라지지 않는 것을 말한다.)

그러니까 GET은 몇 번을 반복해도 동일한 결과가 나온다(나와야 한다). POST는 그렇지 않다.

원칙적으로 이미지 검색 결과 조회같은 것들은 GET으로 만들어야 한다. 그런데 왜 POST를 사용했을까?

우선 GET에는 URL 길이에 제한이 있다. GET 방식에서 파라미터가 길어지면 URL이 길어지고, 길어지다 보면 제한된 길이를 넘게 된다. 제한을 넘으면 원하는 결과가 아닐 수 있다. 하지만 파라미터를 HTTP Message Body에 넣고 POST로 보내면 문제가 쉽게 해결되기 때문이다.

그런데 이 해결 방법에는 댓가가 있다.

GET은 캐시가 되는 특징을 가지고 있다. 왜냐하면 멱등이기 때문이다. 그런데 POST는 캐시를 할 수 없다. 왜냐하면 멱등이 아니니까. (그렇다면 POST를 캐시하도록 만들면 어떨까? message body, 캐시되면 안 되는 다른 POST들… 생각만 해도 답답함이 밀려온다.)

다시 문제로 돌아가서, 요청 파라미터가 늘어나면 POST 방식을 사용해야 하는걸까?

오브젝트들의 좌표와 크기를 모두 한 번에 보내지 않고 하나 또는 조금씩 나눠서 보내면 어떨까? 그렇게 하면 계속 GET을 사용할 수 있고, 클라이언트는 조회 결과를 캐시함으로써 사용자의 데이터와 시간을 아껴줄 수 있다. 그리고 점진적으로 보이는 애니메이션 효과는 덤이다.