※ CRUD 비교 (GPPD) Create = PUT with a new URI POST to a base URI returning a newly created URI Read = GET Update = PUT with an existing URI Delete = DELETE
1-2) 기타 메서드
HEAD : Get과 동일하지만 메세지 부분을 제외하고, 상태줄과 헤더만 반환 [Start-line + Header + CLUF + Body] 중 Header까지의 정보만 요구
OPTIONS : 대상 리소스에 대한 통신 가능 옵션(메서드)을 설명 (주로 CORS에서 사용)
CONNECT : 대상 자원으로 식별되는 서버에 대한 터널을 설정
TRACE : 대상 리소스에 대한 경로를 따라 메세지 루프백 테스트를 수행 - 다시 돌아오는지에 대해
2. GET
2-1) 정의
리소스의 조회
서버에 전달하고 싶은 데이터는 query(쿼리 파라미터, 쿼리 스트링)를 통해서 전달
메세지 바디를 이용해서 데이터를 전달할 수 있으나, 지원하는 곳이 많지 않아 권장하지 않음
2-2) Get의 과정
(a) 리소스 조회1 - 메세지 전달
(b) 리소스 조회2 - 서버 도착
> 서버에서 HTTP메서드를 까고나서 members의 100번 항목이라는 것을 알고
내부 데이터베이스 조회 작업을 수행 JSON, html 등등 응답 데이터를 만듦
(c) 리소스 조회3 - 응답 데이터
> HTTP 버전 + 상태응답 + 상태 메시지 + [HEADER] + [BODY] 의 형태로 응답을 서버가 전송
3. POST
3-1) 정의
요청 데이터의 처리
"메세지 바디를 통해 서버로 요청 데이터 전달"
서버는 요청 데이터를 처리하고, 메세지 바디로 들어온 데이터를 처리하는 기능들을 수행
신규 리소스 등록, 프로세스 처리 등에 사용
※ GET / POST의 차이
- GET은 데이터를 받는것에 더 포커싱이 맞춰져 있음
- POST는 client가 데이터(정보)를 server에게 전달하고 그 정보를 server가 처리해달라는 것이 핵심
※ 메세지 body를 통해 들어온 데이터의 처리에 관한 모든 것을 수행
※ POST는 단순히 데이터를 client가 보내서 등록하는 의미 이상이 있음 → 데이터 등록(의도/컨셉에 맞는) OR 프로세스를 처리해야할 때 evoke할 수 있는 기능 ex) 고객 주문 완료 후, 배달 시작할 때 가게 사장님이 "배달"버튼을 누르면 라이더 배정, 예상 시간 측정 등등... 의 process가 진행될 때(데이터 변경이 아닐지라도) POST 사용
스펙 : POST 메서드는 대상 리소스가, 리소스의 고유한 의미 체계에 따라 요청에 포함된 표현을 처리하도록 요청 → "서버의 의도"에 맞는 데이터 형식을 추가하거나 혹은 새로 생성하는 기능을 POST가 담당 ※ 새 리소스 생성은 PUT이 아닌가 하는데 POST도 가능한가봄(서버에서 따로 데이터 처리를 한다면)
정리 : client가 입력한 리소스 URI에 POST 요청이 오면 데이터를 서버에서 어떻게 처리할지 리소스 마다 "의도/컨셉"에 맞게 따로 정해서 사용해야 함
3-2) POST의 과정
(a) 리소스 등록1 - 메세지 전달
> client가 [ /members ]라고 url을 지정하고 POST를 보내면 server가 그 데이터를 가지고 특정 동작을 하여
저장 혹은 작업을 하는 "약속"을 함 전체 /members 의 하위 리소스 식별 slash를 주지 않아도 됨
> ex) 저장 작업이라 가정
(b) 리소스 등록1 - 신규 리소스 등록
> 저장작업이라는 가정
신규 리소스 식별자 100을 생성 : 서버가 생성
(c) 리소스 등록3 - 응답 데이터
> 201 Created으로 보통 응답, 200도 무방
Header에 Location: /members/100 신규 리소스 경로를 보내줌
+ 등록된 자원에 대한 데이터도 HTTP를 통한 JSON / xml 등의 파일로 전송
4. POST 정리
1) POST /orders/{orderId}/start-delivery
컨트롤 URI라고 함, 리소스 유일 식별과 관계 없음( 리소스만 가지고 URI 설계는 이상적이고 실무에서는 불가능 )
2) 다른 메서드로 처리하기 어려운 경우
ex) 조회용으로 message body에 데이터 넣고 싶음 ( GET으로 보내고 싶지는 않을 때 )
- 보안상의 이유, 쿼리스트링 노출, GET 메세지의 body를 처리안하는 서버인 경우 등등
→ 이런 경우 "조회"이지만 + POST 이지만 조회의 기능도 할 수 있음
결론 : POST는 모든 것을 할 수 있다.
BUT
조회를 한다면 + GET을 쓰는 것이 가능하다면, GET을 쓰면 캐싱을 해주므로 조회라는 목적에 더 유리
