728x90
http 매서드: GET, POST, DELETE, PATCH, PUT
GET - 문서 요청
POST - 문서 등록
DELETE - 문서 삭제
PATCH - 부분 변경
PUT - 변경(없으면 생성?)
GET, POST 는 요청(Request)의 방식임.
Client가 Server한테 값 입력하려고 , 데이터 전달하려고 = 요청하려고 등등 사용함.
| GET | POST |
| - query의 name과 value가 결합되어 스트링 형태로 서버에 전달됨 - URL에 그대로 query의 이름과 값이 같이 연결되어 표현됨 = 쿼리스트링 = ?id=2&tech=endless 이런식으로 http://www.naver.com/news?title=하야 이런식으로 - 그래서 파라미터에 내용이 노출되서 민감한 데이터 다룰 때는 get요청 사용 안한대. |
- Client와 Server 간에 인코딩해서 서버로 전송함 - 쿼리스트링이 url에 노출은 안됨. user한테 파라미터값이 직접적으로 노출이 되는 건 아님. 근데 http요청은 SSL을 이용하는 https가 아닌경우 plain text로 이뤄지게되고, 그러다보니 요청을 열어보면 결국 보여짐(개발자도구로). -> 특별히 보안상 더 뛰어나다고 말하기 힘듦 - 클라이언트에서 데이터를 인코딩 -> 서버층에서 디코딩해서 사용함 (그래서 프론트에서 보내줄 때 인코딩신경씀 urlcomponent인가 뭔가) |
| - form태그 사용할 때 method에 get 입력함. <FORM NAME="form1" ACTION="index.jsp" METHOD="GET"> (GetMapping.. 등등 어노테이션이랑 ajax쓰는 방법도 있음) |
- <from> TAG의 METHOD 속성의 값으로 POST을 입력함. ex) <FORM NAME="form1" ACTION="index.jsp" METHOD="POST"> (PostMapping.. 등등 어노테이션이랑 ajax쓰는 방법도 있음) |
| - 한 번 요청 시 데이터 양이 정해져있음 -> 왜냐? url 길이가 한정적임 -> url은 문자열임 |
- 요청시 데이터 양의 제한이 없음 -> 파일 업로드 등의 동작이 가능함 |
| - db에 추가로 정보를 처리하는 게 아니라, 저장된 data를 단순 요청하는 정도로 사용함 |
- db에 추가하는, 서버에서 갱신 작업을 할 때, 서버에서 정보가 가공되어 응답하는 경우에 사용함 |
| - 쿼리스트링으로 요청이 전송됨? - 해더를 통해 요청이 전송됨? 데이터가 담기는 곳: HTTP 패킷 Header -> 이거 다시 확인해서 글써야함 기억이안나네... |
- 바디를 통해 요청이 전송됨 - HTTP 메세지의 Body에 담아서 전송함 -데이터가 담기는 곳: HTTP 패킷 Body - content-Type에 요청 데이터 타입 표시에 따라 결정됨. |
| 멱등성 보장함 idempotent - 해당 요청을 몇 번을 수행해도, 해당 요청에 대한 결과가 계속 동일하게 들어오는 거임 - 그래서 get 이용해서 게시판을 쓰면, 이건 get의 idempotent 특성을 무시하는 것이며, 문제 발생의 여지가 있음. |
멱등성 보장 안함 non-idempotent - 이게 수학용어임 연산을 해도 결과에 변화가 없다는 특성을 표현한 말임 수학에서 100*1 해도 100이니까 곱셈에 대해 1을 멱등원이라고 부르고 1곱하는 연산이 멱등연산임 - 해당 요청이 수행되면 서버에서 바뀌고, 동일한 결과가 돌아오는 것을 보장할 수 없다는 거임 |
| 캐시될 수 있음 (정적 콘텐츠가 캐시되서, 콘텐츠 변경해도 바뀌지 않는 경우 종종 발생, 그래서 캐시 삭제하고 캐시 안하게 설정해야함) - 브라우저 캐시를 지워주면 서버에 요청보냄 - get으로 요청하면 -> 웹캐시가 요청을 가로챔 -> 서버로부터 리소스를 다시 다운로드 하는 게 아니라, 리소스의 복사본을 반환함 (http 해더에 cache-control 해서 해더를 통해서 캐시 옵션 정할 수 있음) - 캐시를 할 수 있으니까 GET방식으로 글 작성하면 해당 GET요청이랑 그에 대한 응답이 브라우저에 의해 캐시되었다가 다시 사용될 우려가 있음ㅋㅋ. 이러면 캐시로 인해서 동일한 글 또 작성하는 동작이 서버에서 발생될 수 있음 -> 이건 완전 심각한 오류임 |
캐시 안됨 |
| get으로 문서 작성하면 캐시랑 같은 맥락으로 크롤러(검색봇)으로 인한 문제가 발생할 수 있음. bot 또는 crawler (검색봇) 등이 웹페이지 수집을 위해 웹서버에 GET요청을 할 수 있음. 근데 이러한 봇의 요청에 의해 게시판에 엉뚱한 데이터로 글이 작성되어 올라간다든지 ㅋㅋㅋ무친, 서버 쪽의 데이터가 바뀐다면 안되잖슴? => GET으로는 무조건 페이지 보여주기만 해라, 읽거나 검색할 때만 해라 (등록하지마삼) |
=> POST로 무조건 데이터 등록해라 (서버로 데이터 보낼 때) |
| 브라우저 히스토리에 남음 | 히스토리에 안남음 |
| select랑 비슷한 성향임. 서버에서 어떤 데이터를 가져와서 보여줄 때 사용함. 즉, 서버의 어떤 값이나 내용, 상태를 바꾸지 않는 경우에 사용함. READ를 호출하는 경우에 사용함 예를 들면, 게시판에서 글 내용에 대한 목록을 보여주는 경우나 글의 내용을 보는 경우임 Google의 Accelerator사건이 있음 Google이 웹페이지를 빠른속도로 제공하기 위해, 현재 웹페이지에 URL로 Link가 쓰여있으면, 미리 해당 페이지의 내용을 가져와서 Lnki의 내용을 가져옴. 그래서 웹페이지를 전환할 때 빠르게 전환될 수 있게 함 (캐싱 같이) 근데 delete를 GET방식으로 개발해서, 링크의 메일이나 게시글이 마구 지워지는 사태가 발생한 적이 있음 |
insert랑 비슷한 거임. update랑 서버의 값이나 상태를 바꾸기 위해서 사용함. 글쓰기를하면 글의 내용이 DB에 저장/수정시 DB의 값이 변경되게 하는 경우에 post 사용함 Create Upate Delete는 POST를 사용하는 게 맞음 예를 들면, 게시판에 글 써서 올리거나, 수정하는 경우임 |
| 근데 장점이 또 있음. 카카오톡의 공유하기와 같은 기능임. 공유하기 기능은 URL을 보내줌으로써 공유함. POST에는 URL에 담고있지 않아서 공유하기 힘듦. 링크를 공유할 때 URL에 모든 내용을 담고있는게 장점이기도 함. |
* 외울 때 간략하게 보셈
| GET | POST |
| 페이지 요청(읽거나)하거나 검색할 때 사용함 | 데이터 저장할 때 사용함 |
| 쿼리스트링, url 노출 | url 노출 안됨 |
| 해더 Header 로 전송 | 바디 Body 로 전송 |
| 멱등성 보장 idempotent | 멱등성 보장 안함 idempotent |
| 캐싱 가능, 캐시될 수 있음 | 캐싱 불가능 |
| 브라우저 히스토리에 남음 | 히스토리에 안남음 |
| (content-Type에 요청 데이터 타입 표시에 따라 결정됨.) |
참고
https://dev-coco.tistory.com/161
https://interconnection.tistory.com/72