[개발일기] HTTP method GET 조회 vs POST 조회

RESTful API 개발자들은 아래와 같은 질문을 한번 생각해보자.

조회에 사용해야 할 HTTP method는?

당연히 0.1초의 반응속도로 GET method를 얘기해야 정상이다. 하지만 다음과 같은 질문은 생각이 길어질 수 있을 것이다.

반드시 조회에는 GET 뿐만을 사용해야 하나요?

진짜 조회에 사용해야 할 method는 GET 뿐인가?

GET method의 request body

GET은 조회에 사용할 리소스를 URL로 표현한다는 특징이 있다. GET method는 서버에서 리소스를 검색하기 위해 설계되었다. 따라서, 사용자들이 URL만을 보고 직관적으로 어떤 리소스를 활용한 건지 알 필요가 있으므로 일반적으로 Path variable 또는 query parameter를 활용하여 설계가 이루어진다.

하지만,

body안에 조회 조건을 넣어야 하는 GET method를 설계할 경우가 생긴다면 어떻게 할까? 예를 들어, 굉장히 복잡한 조회 조건을 서버에 보내기 위해서 또는 URL에 노출하기 부담스러운 정보를 활용하기 위해서 GET method에 request body를 사용할 수 있을까?

일단 이론상 이 부분을 굉장히 잘 찾아놓은 블로그를 소개한다. 꼭 읽어보자. 흥미로운 내용으로 가득하다.

HTTP GET 메소드와 body

위 글의 필자의 결론은 이렇다. “사용할 수 있고 못할 수도 있다.”

REST 스펙에 대해 다양한 의미로 해석이 가능하고 일부 HTTP client에서도 GET with body를 허용하는 것처럼 API를 설계하는 철학에 따라서 또는 요구사항에 따라서 GET 메서드에 body 값을 추가할 수 있다.

이를 위해 위 글의 필자는 아래 세 가지 주의 사항을 말하고 있다.

GET method 캐싱

GET의 조회 성능을 올리기 위해 GET method에 대해서는 캐싱을 적용한다. 이때, body에 쿼리 조건을 넣은 get은 캐싱을 활용하지 못하는 문제가 발생할 수 있다. URL에 포함된 데이터는 캐시 키의 일부로 사용되므로, 동일한 요청이 반복될 때 서버에 다시 요청하지 않고 캐시에서 데이터를 반환할 수 있다. Request Body는 캐시 키에 포함되지 않으므로, 캐싱 로직에 혼란을 줄 수 있다는 의미이다.

RESTful Semantics

다른 개발자들이 이 컴포넌트가 REST 표준으로 구현되었을 거라 당연시할 것이다. 대부분의 HTTP 클라이언트(브라우저 포함)와 서버는 GET 요청에 Request Body가 포함되지 않는다는 가정 하에 동작한다. 따라서, Request Body가 포함된 GET 요청이 올 경우, 상호 운용성을 보장하기 위해 클라이언트나 서버에서 해당 Body를 무시하는 것이 일반적이다.

지원되지 않는 Client

Spring RestTemplate의 경우 GET 메서드를 사용하는 경우 body 값을 받지 않고 있다. 이처럼 특정 클라이언트 혹은 서버에서는 이러한 표준과 RESTful 원칙을 따름으로써, 일관된 API 설계와 유지보수성을 높이고자 한다.

URL에 정보를 노출하기 부담스러운 조회면?

POST 조회

‘POST’ 메서드는 리소스 생성 또는 수정을 포함하여 서버에 데이터를 제출하는 데 사용되는 것이 일반적이지만 매개변수가 너무 복잡하거나 민감하여 URL에 포함할 수 없는 복잡한 쿼리에도 사용할 수 있다.

• URL의 길이 제한 없이 request body에 복잡한 요청 데이터 전송
  • Post 메서드는 Request Body에 JSON, XML, 파일, 다량의 데이터 등을 전송하는 데 적합하다. 이로 인해 복잡한 쿼리나 다중 필터링 조건을 처리해야 할 때 유리하다. GET 메소드의 URL 쿼리 스트링은 길이 제한이 있으며, 복잡한 데이터 구조를 표현하는 데 적합하지 않지만, Post 메소드는 이러한 제약이 없다.
• 민감한 데이터 보호
  • URL에 데이터를 포함하면, 해당 데이터가 브라우저 기록, 캐시, 서버 로그 등에 저장될 수 있습니다. Post 메서드를 사용하면 이러한 민감한 데이터를 Request Body에 포함시킬 수 있어, URL에 노출되지 않도록 보호할 수 있다. 특히, HTTPS와 함께 사용하면 Request Body 역시 암호화되어 전송된다.

HOW?

레코드를 생성하는 POST와 구분하기 위해서 _search 파라미터와 같은 파라미터를 추가할 수 있다.

• 복잡한 제품 or 민감 정보 활용검색: 클라이언트의 개인정보(디바이스 Mac address, Serial Number)가 페이로드에 포함된 POST /api/v1/client/_search
• 대량 검색: 자세한 정보를 검색하기 위한 제품 ID 목록이 포함된 페이로드가 포함된 POST /api/client/bulk