GET vs POST
들어가며
- 웹개발을 처음 배우면서 작성해 보는 웹 페이지는 아마 간단한 form을 만든 뒤 이름,나이,주소 등을 입력받아 submit 해 DB(또는 파일)에 저장하는 예제일 것이다. (적어도 나는 그랬다.)
- 그리고 그때 처음 만나게 되는 게 바로 form 태그의 method 속성이며, 아마 특별한 교육과정이 아닌 이상 get방식과 post 방식이 있음을 배울 것이다. (get방식 전송의 경우 생략가능하다는 것과 함께)
- 그리고 그 둘의 차이는 get 방식의 경우 URL에 다음과 같이 파라미터가 전송되며,
http://some-url.com?name=firepizza&age=20 - post 방식의 경우 URL에 노출되지 않는 파라미터로 전송된다. 정도로 배우게 된다. (물론 노출되지 않는다고 해서 보안에 완벽하다는 것은 아니다.)
그렇다면 get과 post의 차이는 단지 URL에 파라미터가 노출되는가의 차이 뿐일까?
GET과 POST의 전송방식의 차이
- 표면적으로 보아도 사용법 다르기에 전송방식에도 물론 차이가 있다.
- GET의 경우 전송파라미터가 url에 포함되기 때문에 Request Header에 포함되어 전송되고
- POST의 경우는 Request Body 에 숨겨져(URL에 노출되지 않는다는 의미) 전송된다.
이 때 포함되는 Request Body의 타입을 Header의 Content-Type에 지정해 명시해야 한다.
GET과 POST의 사용목적의 차이
- 두번째로 각 HTTP method는 고유의 사용 목적을 가지고 설계되어 있는데, 이에 대한 궁금증을 해결하기 위해서는 역시 공식문서만한 게 없다.
RFC2616 - GET / RFC2616 - POST
RFC2616 문서에서 정의하고 있는 내용을 간단히 살펴보면,
- GET method는 Request-URI에 의해 특정할 수 있는 정보의 검색(조회) 이며, RFC2616-13의 캐시(cache)조건을 만족하는 경우 캐시할 수 있는 요청이다.
- POST method는 서버가 요청에 포함된(enclosed) 엔티티를 받아들이도록(accept) 하는 요청이다. 그리고 이 요청은 캐시불가능 하나, 적절한 Cache-Control 또는 Expire 헤더 필드를 포함한 경우에는 가능하다는 단서를 달고 있다.
즉, GET은 조회의 성격을 띄고 있으며 캐시가능하고, POST는 서버에게 accept를 요청하는 성격을 띄며 기본적으로 캐시할수 없다는 차이가 있음을 알 수 있다.
여기서 가장 중요한 성격상의 차이는 바로 다음과 같다.
- GET -> retrieve (검색)
- POST -> accept (접수)
즉 HTTP 프로토콜의 설계구조상 GET방식은 검색에 적합하고(CRUD의 R), POST는 접수(CRUD의 CUD)에 가까운 구조라고 볼 수 있을 것이다.
- 그러므로 GET은 서버에서 데이터를 가져오는 용도로 사용되어야지, 해당 요청으로 데이터가 변조되거나 상태가 변해서는 안된다는 것이다.
그리고 POST의 경우 서버의 데이터나 상태를 변경시키는 용도로 사용되어야 한다는 것이다. - 그러나 이론과 실제는 항상 다르듯이, 아마 GET 요청으로 데이터 등록/삭제 등을 해 본 경험이 있을 것이고, URL을 깔끔하게 해 보겠다고 POST method로 조회해 본 경험이 있을 것이다. (혹시 나만?)
- 하지만 위와 같은 사용에는 치명적인 문제가 존재하는데 특히 POST를 조회 기능에 사용하는 경우에 발생한다.
- 만약 아래와 같은 Request-URI에 post방식으로 id값을 전송받아 해당하는 id의 게시물의 html을 전송하는 서버가 있다고 생각해보면 어떨까?
http://some-board.com Request Body : { id: 1 } - 위 URL을 백날천날 지인에게 공유해 봤자 절대 해당 게시글을 읽을 수는 없을 것이다.
- 이는 웹에서 가장 중요한 핵심적인 기능인 Link 기능을 정상적으로 수행하지 못 하는 문제를 야기하며 큰 불편을 만들어 낸다. (http의 태생 자체가 문서를 전송하기 위함임을 생각해보자.) 참고 포스트
- 그리고 이러한 Standard에 맞지 않는 용법으로 인해 발생한 대표적인 사례가 Google의 Accelerator 사건이 있는데, 한번쯤 검색 해 보면 꽤 흥미로운 사례일 것이다.
RESTful의 등장
- 왠지 최근(이제는 최근이 아닐수도 있지만)에 주목받고 있는 RESTful 아키텍쳐는 사실 꽤 오래 된 아키텍쳐이다.
- 2000년 로이 필딩의 박사학위 논문에서 최초로 소개되었으며, 최근에는 왠지 API를 설계할 땐 반드시 RESTful 원칙에 의해 설계/제작 해야만 할 것 같은 느낌을 주는 아키텍쳐 이다.
- 이 기법에서는 HTTP method를 동사(verb 즉, 요청에 의해 수행되어야 하는 행위에 대한 설명)로 사용하는데, RFC2616 문서에서 설계된 각 method들의 목적에 부합하게 사용토록 규정하고 있다.
- 물론 이 역시 강제성을 띄고 있지는 않고 이론적인 부분에 가깝기 때문에 전세계의 모든 개발자들이 기계적으로 지켜 개발하지 않는 한 일률적인 적용은 어렵겠지만…
-
RESTful이 어느정도 유행(?) 하고 있고, 크로스플랫폼을 지원해야 하는 서버 needs가 늘어가고 있는 추세이기에 API 형태의 서버 제공은 늘어갈 것이다. 이제 HTTP의 설계대로 사용하는 것의 중요성을 조금이나마 알게 되었으니, 앞으로의 개발은 이러한 standard를 토대로 진행한다면 보다 쓰기 쉽고 유지보수하기 쉬운 시스템이 만들어지지 않을까?
- 추가로 RESTful에 대해서는 꽤 잘 설명된 블로그가 있어 소개하고자 한다.
이상학 님의 블로그