PUT
- 리소스를 대체(완전히 대체!)
- 리소스가 있으면 대체- 리소스가 없으면 생성
- 쉽게 이야기해서 덮어버림
- 중요! 클라이언트가 리소스를 식별
- 클라이언트가 리소스 위치를 알고 URI지정
- POST와 차이점 :
예) PUT /members/100 HTTP/1.1
Content-Type:application/json
예) POST /members HTTP/1.1
Content-Type:application/json
- 리소스가 있는 경우
- 리소스가 없는 경우
- 주의! 리소스를 완전히 대체한다 : 리소스 수정하기 어려움.
age:50만 넣는경우, username 필드 자체가 없어짐.
PATCH
- 리소스 부분 변경
DELETE
- 리소스 제거
HTTP 메서드의 속성
- 안전(Safe Methods)
- 멱등(Idempotent Methods)
- 캐시가능(Cacheable Methods)
안전
- 호출해도 리소스를 변경하지 않는다
- Q: 그래도 계속 호출해서, 로그 같은게 쌓여서 장애가 발생하면요?
- A: 안전은 해당 리소스만 고려한다. 그런 부분까지 고려하지 않는다.
멱등
- f(f(x))=f(x)
- 한번 호출하든 두 번 호출하든 100번 호출하든 결과가 똑같다.
- 멱등 메서드
- GET : 한번 조회하든, 두번 조회하든 같은 결과가 조회된다.
- PUT : 결과를 대체한다. 따라서 같은 요청을 여러번해도 최종 결과는 같다.
- DELETE : 결과를 삭제한다. 같은 요청을 여러번 해도 삭제된 결과는 똑같다.
POST: 멱등이 아니다. 두번 호출하면 같은 결제가 중복해서 발생할 수 있다.
=> 배송을 두번 누르면 문제가 될 수 있음.
- 활용
- 자동 복구 메커니즘
- 서버가 TIMEOUT 등으로 정상 응답을 못주었을때, 클라이언트가 같은 요청을 다시 해도 되는가?
- Q : 재요청 중간에 다른 곳에서 리소스를 변경해버리면?
- 사용자 1: GET -> username:A, age:20
- 사용자 2: PUT -> username:A, age:30
- 사용자 1: GET -> username:A, age:30 -> 사용자2의 영향으로 바뀐 데이터 조회
A : 멱등은 외부 요인으로 중간에 리소스가 변경되는 것 까지는 고려하지 않는다.
캐시가능 (중요)
- 웹브라우저에 이미지 큰 리소스를 요청 => 같은 리소스 요청시, 로컬pc의 웹브라우저에 저장해놓고 사용 할수 있는지? (캐시)
- 응답 결과 리소스를 캐시해서 사용해도 되는가?
- GET, HEAD, POST, PATCH 캐시가능
- 실제로는 GET, HEAD 정도만 캐시로 사용
- POST, PATCH는 본문 내용까지 캐시 키로 고려해야 하는데, 구현이 쉽지않음.
꾸준히