HTTP 주요 메서드
| GET | 리소스 조회 |
| POST | 요청 데이터 처리, 주로 등록에 사용 |
| PUT | 리소스를 대체, 해당 리소스가 없으면 생성 |
| PATCH | 리소스 부분 변경 |
| DELETE | 리소스 삭제 |
GET
- 리소스 조회
- query를 통해 데이터 전달
- 메시지 바디를 사용해 데이터를 전달 가능
but, 지원하지 않는 곳이 많음
POST
- 메시지 바디를 통해 서버로 요청 데이터 전달
- 새 리소스 생성 (등록)
- 요청 데이터 처리
단순히 데이터 생성, 변경이 아닌 프로세스를 처리하는 경우
POST의 결과로 새로운 리소스가 생성되지 않을 수도 있음
컨트롤 URI - 리소스 만으로 설계하지 않는 경우 - 다른 메서드로 처리하기 애매하거나, 서버 지원 불가한 경우 사용
PUT
- 리소스 대체 : 없으면 생성, 있으면 완전히 대체
기존 리소스 {"username":"young","age":20} 가 있을 때
{"age":50}를 전송하면
👉 {"age":50} 로 대체, ★username 필드가 삭제됨★
- 클라이언트가 리소스를 식별 : 리소스 위치를 알고 URI를 지정
POST/members
PUT/members/100 PATCH
- 리소스 부분 변경
기존 리소스 {"username":"young","age":20} 가 있을 때
{"age":50}를 전송하면
👉 {"username":"young","age":50} 로 age만 변경DELETE
-리소스 제거
HTTP 메서드 속성
안전
- 호출해도 리소스를 변경하지 않음
멱등
- 몇 번 호출하든 결과가 동일
- 멱등 메서드
- GET, PUT, DELETE
- 자동 복구 메커니즘에 활용
- 서버가 timeout 등으로 정상 응답을 못 주었을 때, 클라이언트가 같은 요청을 다시 해도 되는가? 판단 근거
💡 POST는 멱등이 아님 ex) 결제 중복
💡 외부 요인으로 중간에 리소스가 변경되는 것 까지는 고려하지 않음
캐시가능
- 응답 결과 리소스를 캐시해서 사용해도 되는가?
- GET, HEAD, POST, PATCH 캐시 가능
- 실제로는 GET, HEAD 정도만 캐시로 사용
