반응형

HTTP 메서드의 속성

HTTP 메서드의 속성에는

  • 안전 (Safe Methods)
  • 멱등 (Idempotent Methods)
  • 캐시 가능 (Cacheable Methods)

이 있다.

GET같은 경우에는 요청에 Body를 넣을 수 있는데, 지금 실질적으로 되는곳이 있고 안돼는 곳이 있기 때문에 GET요청에 BODY는 사용하지 않는 것이 좋다.

 

먼저, 안전(Safe)에 대해서 살펴보자.

여기서 안전이라는 뜻은, 호출해도 리소스를 변경하지 않는다.라는 것을 뜻한다.

예를 들어서 GET은 안전할까 안전하지 않을까?
GET은 단순히 조회만 하는 것이기 때문에 안전하다.

그런데, POST는? 당연히 안전하지 않다.
DELETE, PUT PATCH는 다 안전하지 않다.

호출했을 때, 뭔가 변경이 일어나는 것은 안전하지 않는 것이다.

 

그런데 안전에 대해서 이러한 질문을 해봐야 한다.
"계속 호출해서, 로그 같은게 쌓여서  장애가 발생하면??"
안전은 해당 리소스만 고려한다. 로그가 쌓여서 장애가 나는 부분까지 고려하지 않는다.

멱등은 한 번 호출하든 두번 호출하든 100번 호출하든 결과가 똑같다.

멱등 메서드

  • GET : 한 번 조회하든, 두 번 조회하든 같은 결과가 조회된다.
  • PUT : 결과를 대체한다. 따라서 같은 요청을 여러번 해도 최종 결과는 같다.
  • DELETE :  결과를 삭제한다. 같은 요청을 여러번 해도 삭제된 결과는 똑같다.
  • POST : 멱등이 아니다! 두 번 호출하면 같은 결제가 중복해서 발생할 수 있다.

 

GET, PUT, DELETE는 멱등하다.

POST는 멱등하지 않다.

멱등이라는 것은 언제 사용하냐면,

자동 복구 매커니즘에 멱등 개념을 사용한다.

예를 들어서, 서버가 TIMEOUT 등으로 정상 응답을 못주었을 때, 클라이언트가 같은 요청을 다시 해도 되는가? 라는
판단근거에 멱등을 사용한다.

만약에 재요청 중간에 다른 곳에서 리소스를 변경해버리면 어떻게 될까?

예를 들어, 사용자 1이 GET으로 조회를 해서 username:A, age:20을 조회했는데

사용자 2가 PUT으로 username:A, age:30 으로 바꿔버렸다고 가정해보자.

그다음에 다시 사용자 1이 GET으로 조회를 하면 username:A, age:30으로 사용자2에 의해 바뀐 데이터를 조회하게 된다.

하지만 이 경우에도 GET은 멱등하다라고 한다.

즉, 멱등은 외부 요인으로 중간에 리소스가 변경되는 것 까지는 고려하지는 않는다.

  • 응답 결과 리소스를 캐시해서 사용해도 되는가?
    • 웹브라우저에 이미지가 큰 것을 요청하면, 다음에 또 그 큰 이미지를 요청하면 비효율적이다.
      그래서 이것을 내 로컬 pc 웹브라우져에 저장하고 있는다. 이것을 캐시라고 한다.
  • GET, HEAD, POST, PATCH는 캐시가 가능하다.
  • 그런데 실제로는 GET, HEAD 정도만 캐시로 사용한다. 왜냐하면, 캐시를 하려면 똑같은 리소스라는 key가 맞아야 하는데, POST, PATCH는 BODY안에도 데이터가 많아서 이것까지 고려하기에 쉽지 않다. GET은 URL만 키로 잡고 캐시를 하면된다.
    • POST, PATCH는 본문 내용까지 캐시 키로 고려해야 하는데, 캐시로 구현이 쉽지 않음
반응형