CH03 HTTP 메서드 속성

강의에서는 HTTP 메서드의 속성으로 안전, 멱등, 캐시가능 이렇게 세 가지를 언급하고 있다.

안전

안전의 경우에는 ‘해당 메소드 타입이 데이터를 변경시키는 행위를 하는가’ 에 초점을 맞춰서 변경시킨다면 안전하지 않다고 보고, 변경시키지 않는다면(GET 과 같이) 안전하다고 본다.

멱등

멱등 은 아래 강의자료를 참고하자.

• f(f(x)) = f(x) (=어느 값에라도 두 번 적용되었을 때, 한 번 적용했을 때와 같은 결과를 주는 경우)

• 한 번 호출하든 두 번 호출하든 100번 호출하든 결과가 똑같다.

  • GET: 한 번 조회하든, 두 번 조회하든 같은 결과가 조회된다.

  • PUT: 결과를 대체한다. 따라서 같은 요청을 여러번 해도 최종 결과는 같다.

  • DELETE: 결과를 삭제한다. 같은 요청을 여러번 해도 삭제된 결과는 똑같다.

  • POST: 멱등이 아니다! 두 번 호출하면 같은 결제가 중복해서 발생할 수 있다.

멱등의 개념 자체는 예전에 백기선님 강의에서 이미 한번 다뤘어서 익숙했는데, 이번 강의에서 멱등의 개념이 왜 필요한가에 대해서 짚고 넘어가서 좋았다. 결국 특정 메소드가 멱등성을 가지고 있느냐 없느냐에 대해서 확실하게 판단하고 있어야 ‘복구 메커니즘’을 구축할 때에 같은 요청을 다시해도 되는가 안되는가를 정할 수 있기 때문이었다.

즉, 멱등성이 보장된다면 서버가 TIMEOUT등으로 응답을 못줬을 시에 길게 생각할 것 없이 다시 같은 요청을 해도 된다고 판단할 수 있는 것이다. 하지만, 멱등성이 보장되지 않는다면 서버가 TIMEOUT등으로 응답을 못줬다고 해도 실제로 해당 서버 내에서 아직 처리중일 수도 있는 등 같은 요청을 두 번 보내고 그 요청들이 모두 데이터에 영향을 준다면 두번 요청하는 행위 자체가 데이터의 정합성을 깨트릴 수 있는 위험한 행위가 된다.

캐시가능

강의 장표로 내용 대체.

• 응답 결과 리소스를 캐시해서 사용해도 되는가?

• GET, HEAD, POST, PATCH 캐시가능

• 실제로는 GET, HEAD 정도만 캐시로 사용

  • POST, PATCH는 본문 내용까지 캐시 키로 고려해야 하는데, 구현이 쉽지 않음