[모든 개발자를 위한 HTTP 웹 기본 지식] 04. HTTP 메서드 - HTTP 메서드의 속성

(인프런) 김영한님의 모든 개발자를 위한 HTTP 웹 기본 지식을 공부하고 리뷰한 글입니다.

4. HTTP 메서드의 속성

<HTTP 메서드의 속성>

1) 안전(Safe Methods)

2) 멱등(Idempotent Methods)

3) 캐시가능(Cacheable Methods)

 

1. 안전(Safe)

호출해도 리소스를 변경하지 않는다

<안전 메서드>

1) 안전O: GET, HEAD

2) 안전X: POST, PUT, PATCH, DELETE

 

Q. 계속 호출하면, 로그 같은 것이 쌓여서 장애가 발생할 수도 있지 않은가?

A. 안전은 해당 리소스만 고려한다. 그런 부분까지 고려하지 않는다.

 

2. 멱등(Idempotent)

f(f(x)) = f(x)

클라이언트가 서버에 같은 요청을 여러 번 해도 결과가 똑같다.

(한 번 호출하든 두 번 호출하든 100번 호출하든 결과는 동일)

<멱등 메서드>

1) 멱등O

- GET: 몇 번을 조회하든 같은 결과가 조회된다.

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

- DELETE: 결과를 삭제한다. 따라서 같은 요청을 여러 번 해도 삭제된 결과는 같다.

2) 멱등X

- POST: 멱등이 아니다! 같은 데이터를 계속해서 POST로 전송하면 서버에서 매번 새로운 리소스를 생성한다(아이디를 새로 발급)

e.g. 두번 호출하면 같은 결제가 중복해서 발생할 수 있음

(참고) HTTP 스펙은 POST가 멱등을 보장하지 않지만, 실제 개발하면서 POST에도 멱등을 보장하게 개발하는 것은 가능하다. 하지만 HTTP 스펙은 GET이 멱등을 보장해야하지만, 실제 GET이 멱등을 보장하지 않게 개발하는 것은 문제가 될 수 있다.

 

<활용>
1) 자동 복구 메커니즘

- 클라이언트가 DELETE를 요청했는데 서버에서 응답이 없을 때, 클라이언트는 요청이 잘 되었는지 모른다.

그래서 클라이언트가 DELETE를 자동으로 재시도한다. 같은 요청을 해도 결과는 같기 때문에, 문제가 되지 않는다.

2) 서버가 TIMEOUT 등으로 정상 응답을 못주었을 때, 클라이언트가 같은 요청을 다시 해도 되는가? 의 판단 근거

 

Q. 재요청 중간에 다른 곳에서 리소스를 변경하면, 처음 요청했을 때의 결과와 재요청 결과가 달라진다. 이렇게 되면 멱등이 아니지 않은가?

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

 

3. 캐시가능(Cacheable) 중요!!

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

예를 들어, 웹 브라우저에서 굉장히 큰 이미지를 요청하면 다음에 또 같은 리소스 서버에 요청할 필요가 없다. 즉, 내 로컬 PC에 웹 브라우저가 리소스를 저장하고 이후에 같은 요청이 들어오면 서버에 요청을 하지 않는다.

 

<캐시가능 메서드>

1) 캐시O: GET, HEAD, POST, PATCH

- 실제로는 GET, HEAD  정도만 캐시로 사용(GET은 URL을 키로 해서 캐시하면되므로 쉬움)

- POST, PATCH는 본문 내용까지 캐시 키로 고려하는 것이 구현이 쉽지 않아 거의 사용X

---

4-4. HTTP 메서드의 속성 질문 정리

Q. PATCH 메서드가 멱등이 아닌 이유는? 외부 요인에 의해 값이 변경되지 않는 이상 PATCH도 항상 같은 결과를 가져오지 않나요?

PUT은 해당 리소스를 완전히 교체해버리기 때문에 멱등이다.

PATCH는 멱등으로 설계할 수도 있지만, 멱등이 아니게 설계할 수도 있다.

즉, PATCH는 리소스의 특정 부분을 변경하는데, 이 변경 방식이 멱등이어도 되고 멱등이 아니어도 된다.

1) PATCH를 멱등으로 설계할 경우

기존에 있던 값과 상관 없이 클라이언트가 요청한 데이터로 변경을 하면 멱등이다.

클라이언트 요청: { "name": "kim" }

다음과 같이 몇번을 호출해도 결과는 { "name": "kim" }으로 동일하다.

2) PATCH를 멱등이 아니게 설계할 경우

기존에 있던 값에 어떠한 연산을 통해 데이터를 변경하면 멱등이 아니다.

예를 들어, 한번 호출할 때마다 나이를 10씩 더하는 식으로 설계를 한다고 가정하자.

클라이언트 요청: { "operation": "add", "age": "10" }

다음과 같이 2번 호출하면 +10이 2번 되어 멱등이 아니게 된다.

 

[참고] https://www.inflearn.com/questions/110644

 

Q. DELETE 메서드를 호출해 파일을 삭제한다고 했을 때, 2번쨰 호출의 응답을 어떻게 하는 것이 코드 레벨에서 좋은 설계인가요?

재요청을 했을 때 서버는 2가지 방식으로 응답할 수 있을 것 같다.

1) 이미 삭제된 파일을 삭제라하고 요청받았으므로 "파일이 존재하지 않습니다"같은 오류메시지와 함꼐 오류 코드를 응답한다.

2) 이미 이전 요청에서 삭제된 파일이지만 현재 파일은 삭제된 상태이므로 삭제를 성공했다고 응답한다.

 

A. 멱등은 클라이언트 관점이 아닌 해당 리소스 관점에서 보는 것이다. 1, 2번 방식 둘다 리소스 관점에서 삭제된 상태이므로 어느 방식을 사용해도 무방하다. 

상황에 따라 다르겠지만 사용성 측면에서 1번이 더 나은 방법이라고 생각한다.

[출처] https://www.inflearn.com/questions/137558

 

Q. PUT, DELETE 메서드가 캐시 불가능인 이유는?

캐시 가능 메서드인가를 판단하는데 중요한 점은 데이터의 변경 관점이다.

캐시라는 것은 원본 데이터가 변경되지 않고 유지되어야 한다. 만약 PSOT, PUT, DELETE, PATCH로 데이터를 변경하게되면 원본 데이터가 변경되기 떄문에 캐시를 유지하기가 어렵다.

GET은 단순 조회이기 떄문에 데이터를 변경하지 않아므로 캐시 가능 메서드이다.

HTTP에서는 GET, HEAD, POST, PATCH를 캐시 가능 메서드라고 선언해두었지만, 실제로는 데이터를 변경할 가능성이 있는 POST, PUT, DELETE, PATCH는 대부분 캐시를 유지하지 않도록 구현한다.

[출처] https://www.inflearn.com/questions/246094