이번 TIL은 인프런의 "모든 개발자를 위한 HTTP 웹 기본 지식"을 학습하고, 정리한 내용입니다.
만약, 제 글의 내용을 퍼갈 시에는 " 모든 개발자를 위한 HTTP 웹 기본 지식 "도 출처에 첨부하시기 바랍니다.
HTTP 메서드는 "클라이언트가 서버에 요청할 때, 기대하는 행동"이다.
HTTP 주요 메서드
기타 HTTP 메서드
connect와 trace는 거의 사용하지 않는다.
GET
GET은 이름 그대로 " 리소스를 조회 "하는 거다.
실무에서는, GET 메서드의 message body에 데이터를 넣지 않는다!!
필요한 경우에는 쿼리 스트링으로 데이터를 보낸다.
왜냐면, 중간에 지원하지 않는 서버들이 많다.
POST
=> 주로 "등록"에 많이 쓴다.
=> /members에 POST 라고 보내면, 어떻게 할 거라고 클라이언트와 서버 사이에 미리 약속을 한다.
=> 그 데이터는 저장하거나, 내부적인 프로세스를 어떻게 하는데 쓸거야! 등등 미리 서로 약속을 해놓는다.
=> 이 예제에서는 POST로 오면, 신규 등록을 한다고 약속됐다고 가정하자!!
=> DB에 등록하기 위해, 100번을 새로 생성하고 등록한다.
=> 그런 다음에, 응답한다.
=> 200 이라고 보내도 된다.
=> 201로 보낼 경우, Location이라고 자원이 생성된 경우도 같이 보내준다.
POST 사용법
POST는 사용법이 다양하다. 단순히, "등록"이라는 의미만을 갖지 않는다.
해당 리소스를 URI에
POST 요청이 오면, 요청 데이터를 어떻게 처리할지 리소스마다 따라 정해야 한다!!
=> 기본적으로 POST는 정해진 것이 없음!!
POST의 주요 역할
새로운 리소스가 생성이 안될지라도, 2번과 같이 서버에서 큰 변화가 일어나는 액션은 POST를 써야한다!!!!!
URI 설계 예외 - 컨트롤 URI
URI는 리소스 단위로 설계해야 한다.
그런데, 위와 같이 어쩔 수 없이 "리소스"만으로 안 될 때가 있다.
그럴 때는 위와 같이 설계하기도 한다.
start-delivery 같이 동사적인 URI가 나올 수 있다.
이런 URI를 " 컨트롤 URI "라고 부른다.
실무에서는 "리소스"만을 가지고 URI를 다 설계할 수는 없다.
기본적으로 "리소스"로 최대한 URI를 설계하되, 어쩔 수없는 것는 부분들은 컨트롤 URI라는 걸로 설계해야한다.
다른 메서드로 처리하기 애매한 경우 - POST
어떤 데이터를 조회용으로 메세지 바디에 데이터를 넣고 싶은데, GET 메세드로는 이런 방식을 지원하지 않는 서버들이 굉장히 많다.
서버들이 이런 식으로 들어오면, 처리를 안 해버리는 경우가 많다.
이런 경우에는 "조회"이지만, POST를 써야 한다.
POST를 쓰면서, 메시지 바디에 조회용 데이터를 넘기면 된다.
정리하면,
POST는 모든 것을 할 수있다.
그러나, "조회"를 할 때는 GET를 쓰는 게 유리하다.
