[HTTP] Get, Post 차이점
by 무작정 개발이번에는 신입 백엔드 개발자 면접에서도 자주 등장하는 기술 면접 질문 중 하나인 GET, POST 방식의 차이점에 대해 정리할 것입니다.
필자는 단순하게 GET/POST 차이점이 데이터를 URL 파라미터에 담아 전송하냐, Body에 담에 전송하냐 정도만 알고 있었지만
이번에 추가적으로 더 깊은 개념을 알게 되어 정리하게 되었습니다. 기술 면접을 대비한다면 이 정도 개념을 알고 있는 것이 좋다고 생각합니다.
벌써 개발자로 일한 지 5개월 차가 되었는데 입사 동기들과 스터디를 진행하면서 HTTP 관련 지식이 부족하다는 것을 느껴
다시 한번 공부를 하고자 해서 정리하게 되었습니다.
1. HTTP Method
HTTP Method는 클라이언트가 서버에 요청의 목적 및 종류를 알리는 수단입니다.
요즘 RestFul API 개발을 주로 하는 추세이고, HTTP Method 종류에는 주로 GET, POST, PUT, DELETE 등이 있습니다.
- 보통 HTTP Method에서 GET 은 주로 서버에서 데이터를 조회 - CRUD 기능에서 : R-Read(조회)
- POST는 서버에 데이터를 생성할 때 주로 사용합니다. - CRUD 기능에서 : C-Create(생성)
[Spring으로 백엔드 개발을 하면 하단의 글을 같이 보면 많은 도움이 되어 첨부합니다.]
[Spring] @RequestMapping이란 그리고 동작 방식
2. GET 방식
GET 방식은 HTTP Method 중 하나로 주로 서버에 데이터를 조회할 때(리소스를 조회) 사용합니다.
URL을 통해 모든 파라미터를 전달하기 때문에 주소창에 전달 값이 노출되고, URL 길이가 제한이 있기 때문에 전송 데이터 양이 한정되어 있고,
형식에 맞지 않으면 인코딩해서 전달해야 합니다. URL에 파라미터가 노출되기 때문에 GET 방식은 중요한 정보를 다루면 안 됩니다. (보안)
[ 추가적으로 알면 더 좋은 GET 방식 특징]
- GET 방식의 요청은 캐시가 가능합니다.
- GET을 통해 서버에 리소스(데이터)를 요청할 때 웹 캐시가 요청을 가로채 서버로부터 리소스를 다시 다운로드하는 대신 리소스 복사본을 반환합니다. HTTP Header에서 cache-control 헤더를 통해 캐시 옵션을 지정할 수 있습니다.
- GET 방식의 요청은 브라우저 히스토리에 남습니다.
- GET은 SELECT 성향이 있어 서버에서 어떠한 데이터를 가져와서 보여주는 용도로 활용
- GET은 CRUD 기능 중에 R-Read(조회)의 역할
3. POST 방식
POST 방식은 HTTP Method 중 하나로 주로 서버에 데이터(리소스)를 생성할 때 사용합니다.
GET과 다르게 POST 방식의 요청은 HTTP Body에 데이터(리소스)를 포함해서 전달하고, 웹 브라우저에는 직접적으로 파라미터가 노출되지 않고 길이 제한도 없습니다.
[ 추가적으로 알면 더 좋은 POST 방식 특징]
- POST 방식의 요청은 캐시 되지 않습니다.
- POST 방식의 요청은 브라우저 히스토리에 남지 않습니다.
- POST 방식은 서버의 값이나 상태를 바꾸기 위해 활용
- GET은 CRUD 기능 중에 C-Create(생성)의 역할
4. GET과 POST의 차이점
☆ 매우 중요 ☆
이제 GET과 POST을 간략하게 비교 정리할 것이고, 가장 중요한 멱등성에 대해 정리할 것입니다.
[사용 목적]
- GET은 서버에서 데이터를 조회할 때, POST는 서버에 데이터를 생성 혹은 수정할 때 사용
- CRUD 기능으로 비유하자면 GET은 Read(조회), POST는 Create(생성)에 가깝다.
[ 요청에 Body 유무 ]
- GET은 URL 파라미터에 요청하는 데이터를 담아 보내기에 HTTP 메시지에 대한 Body가 없다.
- POST는 Body에 데이터를 담아 보내기에 HTTP 메시지에 Body가 존재한다.
[ 멱등성(idempotent) ]
- GET 방식의 요청은 멱등성이 보장된다. + (추가로 POST를 제외한 나머지 HTTP Method 들은 멱등성이 보장된다.)
- POST 방식의 요청은 멱등성이 보장되지 않는다. (추가로 HTTP Method 중 하나인 PATCH 또한 멱등성이 보장되지 않는다.)
(2) 멱등성이 뭔데? 멱등성을 무엇으로 판단하는 거야?
멱등성(idempotent)은 수학이나 전산학에서 연산을 여러 번 적용하더라도 결과가 달라지지 않는 성질을 의미합니다.
이 멱등성을 HTTP Method에 적용하면 다음과 같은 의미를 가집니다.
동일한 요청을 1번 보내는 것과 여러 번 연속으로 보내는 것이 같은 효과를 가지고, 서버의 상태도 동일하게 남을 때 해당 HTTP Method가 멱등성을 가진다고 합니다.
정리하자면 서버의 상태가 멱등성이 보장되는 경우 같은 행위를 여러 번 반복하더라도 같은 효과를 가져야 한다는 것입니다.
멱등성이 보장되지 않으면, 같은 행위를 여러 번 반복하는 경우 요청마다 다른 효과가 발생된다고 생각하면 이해하기 편합니다.
즉, 응답이 다를 수는 있지만, 요청이 의도한 효과를 발휘할 때 멱등성이 유지됨을 의미합니다.
(여러 번 요청을 보내더라도 요청에 의한 서버의 상태는 항상 같음)
아래 (3) 번에서 멱등성에 대해 좀 더 심화 개념을 다룰 것입니다.
아래의 개념에 대해 알면 보다 좋을 것으로 생각됩니다.
(3) 안전한 메서드
안전한 메서드는 GET, HEAD와 같이 서버 측의 상태 정보를 변경하지 않는 메서드를 가리킵니다.
이 안전한 메서드와 멱등성을 지키는 메서드는 서로 다르니 참고하시기 바랍니다!!
간단하게 예시를 들어 보자면
REST API로 간단한 GET, POST, PUT, DELETE를 하는 API를 만들었을 때
먼저 어떤 데이터를 생성한다면 POST 방식의 요청으로 생성합니다.
POST/data
POST 요청을 여러 번 반복하게 된다면 데이터들은 계속 추가될 것이고, 서버의 응답은 반복할 때마다 다른 응답을 나타내며, 다른 효과를
지닐 것입니다. ( 같은 내용의 데이터라도 서로 다른 데이터이다.)
GET/data
GET 요청으로 데이터를 조회합니다.
이 행위를 여러 번 수행한다고, 서버의 상태가 변하지 않고(단순히 조회), 같은 효과를 기대할 수 있습니다. (요청한 데이터를 조회하는 효과)
따라서 멱등성과 안전한 메서드가 성립함을 알 수 있습니다.
PUT/data/2
PUT 요청으로 2 번째 데이터를 수정합니다.
2번 데이터가 없을 경우 데이터가 생성(Create)될 수 있습니다. 이미 데이터가 존재한다면, 데이터는 수정됩니다.
그러면 PUT 방식의 요청이 여러 번 실행되더라도 2번째 데이터는 요청한 그 값으로 수정된 항상 같은 상태일 것입니다.
DELETE/data/2
DELETE 요청은 서버에 데이터가 이미 존재하든, 존재하지 않든 그 데이터는 DELETE 방식의 요청을 보낸 시점에서 삭제됩니다.
추가적으로 HTTP Method에 위의 4가지 말고 다른 몇 개가 존재하니 각자 찾아보는 것을 추천드립니다.
(4) 멱등성 & 안전한 메서드 요약
- GET 방식은 멱등성이 보장되고, POST 방식은 보장되지 않는다.
- 안전한 메서드는 서버의 상태를 절대 변경시키지 않습니다.
- 멱등성이 보장되는 메서드는 서버의 상태를 변경시킬 수도 없을 수도 있습니다. 중요한 점은 우리가 요청한 사항은 Error가 발생하거나, 지연이 발생하지 않는 한 요청에 대한 서버의 상태는 항상 동일합니다.
Reference
Http 아이콘 제작자: kerismaker - Flaticon
블로그의 정보
무작정 개발
무작정 개발