사용자가 어떤 홈페이지로 이동하기 위해서 URL을 브라우저 주소창에 작성하고 엔터를 누르면 원하는 페이지로 이동합니다. 사용자는 단순히 URL(Uniform Resource Locator)을 입력하였지만 서버 내부에서는 클라이언트의 요청에 응답(웹페이지로 표현)하기 위해서 처리를 해주어야 합니다. 여기서 클라이언트가 서버로 요청을 보내는 방법인 HTTP Method에는 크게 GET방식과 POST방식 2가지가 있는데 이것을 정리하도록 하겠습니다.
GET이라는 단어를 우리말로 바꾸면 '가져오다, 얻다' 라는 뜻입니다. 즉 GET 메서드는 다음과 같이 정의할 수 있습니다.
GET 메서드
클라이언트에서 서버로 어떠한 리소스로 부터 정보를 요청하기 위해 사용되는 메서드
조금 더 쉽게 말하면 데이터를 읽거나(READ), 검색(Retrieve)할 때 사용하는 메서드 입니다.
GET은 요청을 전송할 때 URL 주소 끝에 파라미터로 포함되어 전송되며, 이 부분을 쿼리 스트링(QueryString) 이라고 부릅니다.
EX)
http://www.example.com/getYoil?year=2021&month=10&day=1
위 예는 앞서 말한 쿼리스트링을 포함한 URL입니다. 파라미터인 year과 month, day를 통해 값을 전달받을 수 있습니다.
만약, 요청 파라미터가 여러 개이면 &로 연결합니다.
또한, GET 요청은 오로지 데이터를 읽을 때만 사용되고 수정할 때는 사용하지 않습니다.
따라서 이런 이유로 사용하면 안전하다고 간주됩니다. 즉, 데이터의 변형의 위험없이 사용할 수 있다는 뜻입니다.
GET은 불필요한 요청을 제한하기 위해 요청이 캐시될 수 있습니다.
파라미터에 내용이 노출되기 때문에 민감한 데이터를 다룰 때 GET 요청을 사용해서는 안 됩니다. (보안에 취약하다.)
GET 요청은 브라우저 기록에 남습니다.
GET 요청을 북마크에 추가할 수 있습니다.
GET 요청에는 데이터 길이에 대한 제한이 있습니다.
Get 요청은 성공시, 200(Ok) HTTP 응답 코드를 XML, JSON뿐만 아니라 여러 데이터(html, txt등..), 여러 형식의 데이터와 함께 반환합니다.
GET 요청은 멱등(idempotent)합니다.
GET방식을 사용하여 데이터를 노출시키는 경우는 개인정보가 포함되지 않는 상황에서 캐싱을 하여 속도를 높이거나 즐겨찾기를 편리하기 위해 사용되는 경우가 많습니다.
우리가 어떤 물건 a에 대해서 즐겨찾기를 추가하면 그 물건의 이름이 a라는 정보를 url에 추가하여 즐겨찾기를 생성할 수 있는 것입니다.
캐싱(Caching)
캐싱이란 한번 접근 후, 또 요청할시 빠르게 접근하기 위해 레지스터에 데이터를 저장시켜 놓는 것입니다.
멱등(idempotent)
연산을 여러 번 적용하더라도 결과가 달라지지 않는 성질을 의미한다.
GET은 Idempotent, POST는 Non-idempotent하게 설계되었습니다.
여기서 GET이 Idempotent하도록 설계되었다는 것은 GET으로 서버에게 동일한 요청을 여러 번 전송하더라도 동일한 응답이 돌아와야 한다는 것을 의미합니다. 이에 따라 GET은 설계원칙에 따라 서버의 데이터나 상태를 변경시키지 않아야 Idempotent하기 때문에 주로 조회를 할 때에 사용해야합니다.
예를 들어, 브라우저에서 웹페이지를 열어보거나 게시글을 읽는 등 조회를 하는 행위는 GET으로 요청하게 됩니다.
반대로 POST는 Non-idempotent하기 때문에 서버에게 동일한 요청을 여러 번 전송해도 응답은 항상 다를 수 있습니다.
이에 따라 POST는 서버의 상태나 데이터를 변경시킬 때 사용됩니다.
게시글을 쓰면 서버에 게시글이 저장이 되고, 게시글을 삭제하면 해당 데이터가 없어지는 등 POST로 요청을 하게 되면 서버의 무언가는 변경되도록 사용됩니다. 이처럼 POST는 생성, 수정, 삭제에 사용할 수 있지만, 생성에는 POST, 수정은 PUT 또는 PATCH, 삭제는 DELETE 가 더 용도에 맞는 메소드라고 할 수 있습니다.
POST라는 말을 우리말로 바꾸면 '부치다, 제출하다' 정도의 의미를 가지고 있습니다. 지금 작성하고 있는 블로그도 포스팅(Posting)한다고 하는데 같은 의미 입니다. 즉 POST는 다음과 같이 정의할 수 있습니다.
POST 메서드
리소스를 생성/업데이트하기 위해 서버에 데이터를 보내는 데 사용하는 메서드
GET과 달리 전송해야될 데이터를 HTTP 메세지의 Body에 담아서 전송합니다.
그리고 그 Body의 타입은 요청 헤더의 Content-Type에 요청 데이터의 타입을 표시 따라 결정 된다. (POST로 요청을 보낼 때는 해야 합니다.)
HTTP 메세지의 Body는 길이의 제한없이 데이터를 전송할 수 있습니다. 그래서 POST 요청은 GET과 달리 대용량 데이터를 전송할 수 있는 이유도 이 때문입니다.
이처럼 POST는 데이터가 Body로 전송되고, 내용이 눈에 보이지 않아 GET보다 보안적인 면에서 안전하다고 생각할 수 있지만, POST 요청도 크롬의 개발자 도구, Fiddler와 같은 툴로 요청 내용을 확인할 수 있기 때문에 민감한 데이터의 경우에는 반드시 암호화해 전송해야 합니다.
POST 요청은 캐시되지 않습니다.
POST 요청은 브라우저 기록에 남아 있지 않습니다.
POST 요청을 북마크에 추가할 수 없습니다.
POST 요청에는 데이터 길이에 대한 제한이 없습니다.
Post 요청 중 자원 생성은 201(Created) HTTP 응답 코드를 반환합니다.
Post 요청은 멱등(idempotent)하지 않습니다.
- | GET | POST |
---|---|---|
캐시 | ⭕️ | ❌ |
브라우저 기록 | ⭕️ | ❌ |
북마크 추가 | ⭕️ | ❌ |
데이터 길이 제한 | ⭕️ | ❌ |
HTTP 응답 코드 | 200(Ok) | 201(Created) |
언제 주로 사용하는가? | 리소스 요청 | 리소스 생성 |
리소스 전달 방식 | 쿼리스트링 | HTTP Body |
idempotent | ⭕️ | ❌ |
https://velog.io/@songyouhyun/Get%EA%B3%BC-Post%EC%9D%98-%EC%B0%A8%EC%9D%B4%EB%A5%BC-%EC%95%84%EC%8B%9C%EB%82%98%EC%9A%94#get-%EC%9A%94%EC%B2%AD%EC%97%90-%EB%8C%80%ED%95%9C-%EA%B8%B0%ED%83%80-%EC%B0%B8%EA%B3%A0-%EC%82%AC%ED%95%AD
https://mangkyu.tistory.com/17
GET 메서드의 경우 캐싱이 되고 POST 메서드의 경우 캐싱이 안된다고 나와있는데 네트워크 수업시간에 배우긴 했지만 시간이 많이 지났으므로(이게 블로그를 시작한 이유인 것 같다. 8년간 다이어리는 꾸준히 써왔지만 왜 공부한 기록을 남길 생각은 못했을까.. 그래도 늦었지만 지금부터라도 하자) '캐시'라는 개념에 대해 조금 더 알아봐야 겠다.
빠른 시일 내에 '캐시'에 대해 공부하고 블로그에 포스팅 해야겠다.