#안전

여러번 해당 메소드를 호출해도 리소스를 변경하지 않는것을 안전하다라고 표현한다.
- GET 메소드: 안전한 메소드(리소스를 변경하지 않으므로)
- POST, PUT, PATCH, DELETE 메소드 : 안전하지 않는 메소드(리소스를 변경시키므로)

즉 여러번 메소드를 여러번 호출하면 안전하지 않다는 것으로, GET 을 제외한 POST, PUT, DELETE 와 같은 메소드들을 호출하는 것은 안전하지 않다는 것입니다. 반대로 여러번 호출해도 변경사항이 없는 것을 안전하다고 표현합니다.

그런데 아래와 같은 질문을 할 수 있다.

계속 호출을해서 서버에 로그같은 것들이 쌓여서 터져서 서버에 장애가 발생할 수 있는데, 이에 대해 안전이라는 개념은 고려를 하지 않습니다. 즉, 안전이라는 개념은 해당 리소스가 변하냐 변하지 않느냐만을 고려하지, 세부적인 사항들은 고려하지 않습니다.

---

#멱등

멱등이라는 것은 한번 호출하든, 수백번 여러번 호출하든 결과가 계속 똑같은것을 의미합니다.
수학에서 많이 보셨을 개념인데, 기호로 표현하자면 "f(f(x)) = f(x)" 가 되는 것입니다.

저희는 멱등인 메소드와, 멱등이 아닌 메소드로 구분지을 수 있습니다.

#멱등 메소드 : GET, PUT, DELETE

GET : 한번 조회하든, 두번 조회하든 같은 결과가 조회되므로 멱등입니다.
PUT : 결과를 대체한다. 따라서 같은 요청을 여러번 해도 최종 결과는 같다.
DELETE : 결과를 삭제한다. 같은 요청을 여러번 해도 리소스가 삭제된 결과는 똑같다.

PUT 이 왜 멱등 메소드일까?

여기서 PUT 은 왜 멱등 메소드일까요?
PUT 은 기존것을 아예 날려버리고 내가 새롭게 보낸것으로 내용을 새롭게 덮어버리는 특성을 지닙니다.

PUT 요청을 첫번째로 보낼경우 그에 맞춰서 데이터가 생성이 될겁니다. 그 뒤로 2번째 PUT 요청을 인풋값을 동일하게 맞추어서 보내면 첫번쨰와 두번쨰 결과가 동일할겁니다. 이렇게 동일한 인풋을 기반으로 계속 PUT 요청을 수백번 보내도, 결과적으로 생성되는 데이터 결과는 동일합니다.

DELETE 는 왜 멱등 메소드일까?
DELETE 도 생각해봅시다.
원하는 리소스에 대해 삭제하는 DELETE 요청을 보내면 리소스가 삭제가 될겁니다. 그런데 또 동일하게 DELETE 를 요청하면, 그대로 리소스는 이전의 DELETE 요청과 동일하게 리소스가 삭제된 상태가 동일하게 됩니다

---

#멱등이 아닌 메소드 : POST

POST : 멱등이 아니다. 결제 기능을 생각해보면, 1번 결제하는것과 100번 결제하는 것은 다르다.

POST 는 멱등이 아닙니다. 결제 기능을 POST 요청으로 처리하는 것을 생각해봅시다.
앨범을 구매하는 결제를 1번하는 것과 2번 하는 결과가 동일할까요? 당연히 아닙니다. POST 요청으로 결제를 1번한다면 1개의 앨범이 생성되고, 2번한다면 2개의 앨범이 생성됩니다.