GET 방식과 POST 방식

GET 방식과 POST 방식은 웹 애플리케이션에서 데이터를 전송하는 HTTP 요청 메서드이다. 오늘은 이 두 가지 방식의 특징 및 비교를 해보겠다.

예시

example.com/login?username=johndoe&password=123456

데이터를 URL의 쿼리 문자열에 추가하여 전송함. 위와 같이, 데이터(username과 password)가 URL의 쿼리 문자열에 추가되어 전송됨. 하지만 이 방식은 URL에 모든 정보가 포함되므로 누구나 쉽게 데이터를 볼 수 있으므로 민감한 정보를 전송하기에는 적합하지 않음

URL 예시
example.com/login

HTTP 요청 본문 예시

POST /login HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded

username=johndoe&password=123456

데이터를 HTTP 요청의 본문(body)에 포함하여 전송함. 동일한 로그인 폼을 POST 방식으로 제출하면 URL은 예시와 같이 단순하지만, 실제 데이터는 HTTP 본문에 숨겨져 있음. username=johndoe&password=123456 데이터는 요청 본문에 포함되어 전송되므로 URL에 나타나지 않으므로 데이터 보안 측면에서 더 안전함.

데이터 조회 (Read-only)
- GET 방식은 서버에서 데이터를 조회하거나 가져올 때 사용됨. 예를 들어, 웹 페이지를 요청할 때, 검색 쿼리를 제출할 때, 특정 자원의 정보를 가져올때 사용
- 예시 : 검색 엔진에서 검색어를 입력하고 결과를 가져오는 요청(example.com/search?q=openai)
북마크 및 링크 공유 가능
- GET 방식의 URL 브라우저의 주소창에 표시되며, 이 URL을 복사하여 북마크하거나 다른 사람과 공유할 수 있음. 이러한 특성은 GET 요청이 서버의 상태를 변경하지 않는 안전한 요청에 사용되도록 함
- 예시 : 뉴스 웹사이트에서 특정 기사 페이지를 공유할 때 (example.com/articles?id=123)
아이템 리스트나 데이터를 필터링
- 특정 범주에 따라 데이터를 필터링하거나 정렬하는 요청에도 GET이 사용됨. 예를 들어, 온라인 쇼핑몰에서 특정 범주의 제품 목록을 요청할 때, 쿼리 문자열로 범주와 정렬 조건을 지정
- 예시 : example.com/products?category=electronics&sort=price_asc
API 요청
- RESTful API에서 GET 요청은 자원의 상태를 읽어오는 데 주로 사용됨
- 예시 : GET /users 는 사용자 목록을 반환

데이터 생성 및 서버 상태 변경
- POST 방식은 서버의 상태를 변경하는 요청에 사용함. 주로 데이터를 서버에 제출하거나 새로운 자원을 생성할 때 사용됨
- 예시 : 회원가입 폼 제출 (example.com/register)
민감한 정보 전송
- 로그인, 결제 정보전송 등 민감한 데이터를 서버로 전송할 때 POST 방식을 사용함. URL에 데이터가 포함되지 않기 때문에 더 안전하게 전송할 수 있음
- 예시 : POST /login으로 사용자의 아이디와 비밀번호를 전송
폼 데이터 제출
- 웹 폼(form)에서 사용자가 입력한 데이터를 서버로 제출하는 경우 POST 방식을 사용함. GET 방식보다 긴 데이터를 보낼 수 있으며, 특수 문자가 포함된 데이터도 안전하게 전송할 수 있음
- 예시 : 피드백 제출 폼, 문의하기 양식 등
파일 업로드
- 파일 업로드와 같은 대량의 데이터 전송에도 POST 방식을 사용함. 본문에 데이터를 포함하므로 파일의 크기나 내용에 제약이 없음
- 예시 : 이미지나 문서를 서버에 업로드할 때
API 요청
- RESTful API에서 POST 요청은 새로운 자원을 생성하는 데 사용됨
- 예시 : POST /users는 새로운 사용자를 생성

캐싱 가능
- GET 요청은 서버의 상태를 변경하지 않으므로 브라우저나 중간 프록시 서버에서 응답을 캐시할 수 있음. 이를 통해 동일한 요청에 대해 서버에 다시 요청하지 않고 캐시된 응답을 사용할 수 있음.
- 예를 들어, 웹사이트의 정적 콘텐츠(이미지, 스타일시트, 자바스크립트 파일 등)는 GET 요청을 통해 가져오며, 브라우저는 이를 캐시하여 사용자가 페이지를 다시 방문할 때 빠르게 로드할 수 있음
브라우저 기록에 남음
- GET 요청을 통해 방문한 URL은 브라우저 히스토리에 저장됨. 사용자가 이전에 방문한 페이지를 쉽게 다시 방문할 수 있도록 도와줌. 하지만 URL에 민감한 정보가 포함될 경우, 브라우저 기록을 통해 정보가 노출될 위험이 있음. 또한, 자동 완성 기능으로 URL이 노출될 수 있음

기본적으로 캐시되지 않음
- POST 요청은 서버의 상태를 변경하는 요청으로 가정되므로, 브라우저는 일반적으로 POST 요청의 응답을 캐시하지 않음. 응답을 캐시할 경우 동일한 요청이 서버의 상태를 잘못 변경할 수 있어 위험함. 서버에서 POST 응답을 명시적으로 캐시하도록 설정할 수는 있지만, 이는 매운 드문 경우임
브라우저 기록에 남지 않음
- POST 요청의 URL은 브라우저 기록에 남을 수 있지만, 요청 본문에 포함된 데이터는 기록되지 않음. 따라서 브라우저 기록을 통해 전송된 데이터가 노출될 위험이 줄어듬. 다만, POST 요청 후 뒤로 가기 버튼을 누를 때 '폼을 다시 제출하시겠습니까?'와 같은 경고 메시지가 표시될 수 있음. 이는 브라우저가 동일한 POST 요청을 다시 전송할지 묻는 것임.

특징	GET 방식	POST 방식
데이터 전송 방법	URL 쿼리 문자열로 전송 (민감한 정보 포함 금지)	HTTP 요청 본문에 포함하여 전송 (HTTPS 권장)
보안성	URL에 데이터가 노출되어 보안에 취약 (HTTPS 필수)	본문에 포함되어 URL에는 나타나지 않지만 HTTPS 필수
데이터 길이 제한	URL 길이 제한 (일반적으로 2048자)	제한 없음 (서버 설정에 따라 달라질 수 있음)
캐싱 가능성 및 브라우저 기록	브라우저가 요청을 캐시하고 기록할 수 있음	기본적으로 브라우저가 요청을 캐시하지 않으며, 본문 데이터는 기록에 남지 않음
사용 용도	데이터 조회, 서버 상태를 변경하지 않는 요청에 적합	데이터 생성, 업데이트 등 서버 상태를 변경하는 요청에 적합
예시	검색 요청, 데이터 필터링 및 정렬 (`example.com/search?q=openai`)	로그인, 회원가입, 파일 업로드, 민감한 정보 전송 (`POST /login`)