1.안전
호출해도 리소스를 변경하지 않는것을 말한다.
만약 같은 요청을 호출해서 로그 같은게 쌓여서 장애가 발행하면?
안전 속성은 리소스에 대해서만 고려한다.
이외의 부분은 고려하지 않는다.
get은 안전 post 등은 변경이 일어나서 안전하지 않다.
2.멱등(itenpotent) 전제는 "같은" 요청을 여러번 한다는것
f(f(x)) = f(x)
같은 요청을 한번 호출하든 두번 호출하든 100번 호출하던 항상 결과가 똑같은걸 말한다.
멱등 메서드,
get - 한번 조회하든 , 두번 조회하든 같은 결과가 조회된다.
put - 결과를 대체한다, 따라서 같은 요청을 여러번 해도 최종결과는 같다.
delete - 결과를 삭제한다. 같은 요청을 여러번해도 삭제된 결과는 똑같다.
post - 멱등하지 않다. 두번 호출하면 같은 결제가 중복해서 발생할 수 있다.
put은 결과를 덮어 버리기 떄문에 멱등이다.
멱등 활용
자동 복구 메커니즘
서버가 timeout 등으로 정상응답을 못주었을때
클라이언트가 같은 요청을 다시해도 되는가? (판단근거)
//서버에 응답이 없을때 서버가 메서드를 재시도하는데 이것은 해도 괜찮은지 판단.
멱등 예
재요청 중간에 다른곳에서 리소스를 연결해버리면?
// 같은 요청을 하지만 제3자에 의해 변경되여 결과값이 달라지는 경우
사용자1 : get -> username :a , age:20
사용자2 : put -> username :b , age:30
사용자1 : get -> username :b , age:30 (사용자 2에의해 값이 변경된 상황)
멱등은 외부요인으로 중간에 리소스가 변경되는것까지는 고려하지 않는다.
내가 동일한 요청을 다시한 경우를 예상하지 중간에 값이 바뀌는건 예상하지 않는다.
중간에 제3자에 의해 리소스가 바뀌는건 서버가 고려해야할 사항
3.캐시가능
응답 결과 리소스를 캐시해서 사용해도 되는가?
get, head , post , patch 캐시 가능
실제로는 get , head 정도만 캐시로 사용 (key가 맞아야 하는데 post는 어렵다.)
post , patch는 본문 내용까지 캐시키로 고려해야 하지만 구현이 어려움
get은 URL만 아서 캐시키로 사용할수 있다.
'HTTP' 카테고리의 다른 글
3월 9일 HTTP API전송 (0) | 2023.03.09 |
---|---|
3월 9일 HTTP 실제 활용 (0) | 2023.03.09 |
3월 8일 HTTP put,patch,delete (0) | 2023.03.08 |
3월 8일 HTTP 메서드 (0) | 2023.03.08 |
3월 8일 HTTP 메시지 (0) | 2023.03.08 |