책에 없는 내용입니다!
같은 연산을 여러번 실행해도 매번 결과가 동일한 성질!
멱등성의 성질을 HTTP에도 적용할 수 있다.
동일한 요청을 계속 보내도 서버의 상태가 동일할 때 해당 HTTP 메서드가 멱등성을 가진다고 말한다. 응답 Status가 달라도 서버의 자원 상태가 매번 동일한 상태면 된다.
GET은 서버에 존재하는 리소스를 조회하는 메서드이기 때문에 멱등성을 가진다. 여러번 수행되어도 결과값은 동일하다.
서버의 리소스 전체를 대상으로 요청 내용에 따라 대체하기 때문에 멱등성을 가진다. API를 올바르게 구현하였다면 동일한 요청으로 여러번 보내도 응답 후 서버의 상태는 동일할 것이다.
존재하는 데이터를 삭제한 결과와 이미 존재하지 않은 결과를 삭제하려는 시도에 대한 응답 코드는 서로 다르겠지만, (200 OK 또는 404 NOT FOUND) 서버의 상태 자체는 변하지 않으므로 올바르게 구현되었다면 여러번 수행되어도 멱등성이 보장될 것이다.
리스트의 마지막 데이터 삭제와 같은 DELETE 요청 API는 구현해서는 안된다.
POST는 동일한 요청 객체가 여러개 생성될 수도 있기 때문에 멱등성을 보장하지 않는다. POST가 호출될 때마다 DB에는 중복 데이터가 생성될 것이다. 서버 상태가 달라진다!
POST 멱등성이 보장되지 않기 때문에 주의해야할 부분 - PRG 패턴
https://programmer93.tistory.com/76
https://it-eldorado.tistory.com/68
PATCH는 멱등성을 보장할 수도 있고, 보장하지 않을 수도 있다.
API 구현 방식에 따라 달라진다.
PATCH /user
{
age: 10
}
매번 age가 10으로 변경된다 -> 멱등성이 보장된다.
PATCH /user
{
"operation": "add",
"age": 10
}
age에 10만큼 add하라 -> 멱등성이 보장되지 않는다.
서버의 상태가 매번 달라진다.
리소스의 전체를 대체 / 부분 변경
안전한 메서드란 서버의 상태를 변경시키지 않는 메서드를 의미한다.
모든 안전한 메서드는 멱등성을 갖는다. 그러나 그 역은 성립하지 않는다.
PUT과 DELET 메소드
는 멱등성을 갖는다고 이야기 했다. 하지만 PUT은 리소스를 수정하고, DELETE는 리소스를 제거하므로 안전한 메소드라고는 이야기할 수 없다. 서버의 상태가 변경되기 때문에!
즉, 멱등성을 갖는 메소드가 서버의 상태를 변경하지 않는다고 오해하면 안된다. 멱등성을 갖는 메소드도 서버의 상태를 변경시킬 수 있다. 멱등성의 핵심은 "요청에 대한 서버의 상태가 항상 같은가?" 이다.
멱등성 : "요청에 대한 서버의 상태가 항상 같은가?"
안전한 메서드 : 서버의 상태가 변경되지 않는 것
https://hudi.blog/http-method-idempotent/
https://velog.io/@ziyoonee/http의-멱등성