GET , HEAD method는 절대 불러오는 action 이외에 다른 의미를 가지면 안된다는 convention이 생겼음. 이 메소드들은 safe 해야한다. 이는 유저에게 POST, PUT , DELETE 와 같은 다른 메소드들을 사용했을 때 unsafe 할 수 있는 action이 요청되었음을 알게 해주는 기준점이 되어준다.GET request가 서버에게 어떤 side-effect를 만들지 않는다고 확신할 수 없다. 실제 특정 dynamic resources는 이 기능을 고려한다. 여기서 중요한 차이점은 사용자가 side-effect 자체를 요청한것이 아니기때문에 우리는 그들에게 책임을 요구할 수 없다는 것이다.method는 또한 멱등성(idempotence)라는 성질을 가진다.
이는 오류 또는 만료 문제는 제외하고 N번의 request(N>0)시에 side-effects는 단일 request와 동일하다는 것을 말한다.(결과가 동일하다는 이야기인듯)
GET, HEAD, PUT, DELET는 이러한 속성을 공유한다.
또한 OPTIONS method와 TRACE SHOULD NOT도 side effect를 가지며 inherently idempotent하다.
하지만 request를 여러개 보냈을 때(sequence of requests) 각각이 idempotent하더라도 그 sequence는 non-idmpotent할 수 있다(반대로 전체 시퀀스를 한번 실행했을 때의 결과가 항상 해당 시퀀스의 전체 또는 일부를 재실행하여 나온 결과, 즉 변경되지 않는 결과라면 시퀀스는 idempotent하다)예를들어 sequence의 결과가 이후 동일한 sequence를 실행했을 때 변경될 value 값에 영향을 받는다면 이는 non-idempotent하다.
동일한 리소스 set에서 어떤 동시(concurrent)연산도 실행되지 않는다면 side effect가 없는 sequence는 idempotent하다.