[Network] HTTP 메서드 속성 - 안전성, 멱등성, 캐시 가능성 정리하기

 

HTTP 메서드의 속성을 고려하여 어떻게 서버에 요청을 보내냐에 따라 API 설계, 복구 매커니즘, 캐시 최적화 등 설계 로직이 달라질 수 있습니다.

 

HTTP 메서드의 속성인 안전성, 멱등성, 캐시 가능에 대해 알아봅시다.

1. 안전성(Safe)

HTTP 메서드의 안전성이란, 해당 메서드를 여러번 호출해도 리소스가 변경되지 않는 성질을 말합니다.

 

1-1. 안전한 메서드에는 어떤 것이 있나요?

• 안전한 메서드: GET, HEAD, OPTIONS, TRACE
• 안전하지 않은 메서드: POST, PUT, PATCH, DELETE

 

GET 메서드는 단순히 데이터를 조회하므로 해당 리소스를 변경하지 않기 때문에 안전합니다.

반면, POST, PUT, PATCH, DELETE 메서드는 여러 번 호출할 경우 데이터가 변경되거나, 서버에서 삭제되기 때문에 안전하지 않다고 볼 수 있습니다.

 

1-2. 이런 경우는 안전하지 않나요?

만약 수많은 GET 요청에 의해 로그가 쌓이고 서버에 장애가 발생한다면 안전성에 부합되지 않을까요? 그렇지 않습니다.

 

여기서 안전이라는 개념은 데이터의 일관성 유지라는 맥락에서 파악할 수 있습니다.

즉, "대상 리소스가 변하지 않는다"면 안전한 메서드입니다.

2. 멱등성(Idempotent)

HTTP 통신에서의 멱등성이란, 동일한 요청을 여러 번 호출해도 동일한 결과를 갖는 것을 말합니다.

다시 말해, 요청을 한 번 보내든 여러 번 보내든 결과가 같은 것을 의미합니다.

 

2-1. 멱등성 메서드에는 어떤 것들이 있나요?

상태코드는 바뀔 수도 있지만, 서버의 상태가 변하지 않으면 해당 HTTP 메서드가 멱등성을 가진다고 말할 수 있습니다.

 

각 HTTP가 멱등성을 갖거나, 갖지 않는 이유에 대해 알아봅시다.

 

• 멱등성 메서드: GET, PUT, DELETE, PATCH
  • GET: 여러 번 요청해도 같은 결과가 조회
  • PUT: 해당 리소스를 완전히 교체하여 동일한 결과
  • DELETE: 해당 리소스는 삭제된 상태 반환
  • PATCH: 리소스의 일부만 수정할 경우 동일한 결과
• 비멱등성 메서드: POST, PATCH
  • POST: 요청 시마다 새로운 리소스를 생성
  • PATCH: 동작이 증가를 통한 변경일 경우 다른 결과

 

2-2. 멱등성은 왜 필요한가요?

멱등성이라는 개념은 왜 필요할까요?

 

멱등은 동일한 메서드를 또다시 호출해야 하는 상황에서, 호출해도 상관이 없는지 여부를 판단할 때 활용할 수 있습니다.

 

예를 들어, 클라이언트가 서버로 HTTP 메시지를 전송하였는데 정상적인 응답을 받지 못한 경우, HTTP 메서드의 멱등성 유무가 중요해집니다.

 

GET이나 DELETE 같은 메서드들은 여러 번 호출하여도 결과는 변함이 없기 때문에 통신 장애 시 동일한 요청을 재전송해도 문제가 없을 것입니다. 하지만 POST처럼 멱등하지 않은 메서드는 재요청 시 큰 문제를 야기할 수 있습니다. 특히 중복 결제와 같은 상황을 생각해 볼 수 있습니다.

 

이처럼 자동 복구 매커니즘의 사용 가능 여부에 있어서 HTTP의 멱등적인 속성은 설계의 중심이 됩니다.

 

2-3. 이런 경우는 멱등성을 가지지 않나요?

그렇다면 재요청 중간에 다른 곳에서 리소스를 변경한다면 어떻게 될까요?

 

• A: GET -> {username:kim, age:20}
• B: PUT -> {username:kim, age:30}
• A: GET -> {username:kim, age:30} => B의 영향으로 바뀐 데이터 조회

 

A의 GET 요청 중간에 B가 PUT 리소스를 변경하고, 그 후에 A가 GET 요청을 통해 리소스를 다시 조회하는 상황을 가정해봅시다. 멱등성이 있는 GET 메서드를 사용하였지만, B의 개입으로 인해 응답 결과가 달라지게 됩니다.

 

그러나 멱등성의 여부는 외부 요인으로 인해 중간에 리소스가 변경되는 것은 고려하지 않으며, 또한 서버의 상태를 기준으로 판단하기 때문에 GET의 멱등성은 유지됩니다.

3. 캐시 가능(Cacheable)

캐시 가능성은 응답 결과를 캐싱해서 효율적으로 사용할 수 있는가의 여부입니다.

 

캐시 가능한 메서드는 캐시할 수 있는 HTTP 응답을 생성하여 이후 동일한 리소스에 대한 재요청을 방지합니다.

 

3-1. 캐시란 무엇인가요?

캐시(Cache)란 데이터나 값을 미리 복사해 놓는 임시 저장소를 가리킵니다.

 

처음 웹 사이트에 접속할 때 서버로부터 리소스(HTML 파일, JavaScript, 이미지)를 모두 받아옵니다.

 

이후 클라이언트가 서버에 한 번 요청했던 데이터를 매 요청마다 다시 전송할 필요가 없도록 웹 브라우저는 리소스를 캐시 합니다. 웹 사이트에 재방문할 경우 캐시에서 리소스를 가져오기 때문에 더욱 빠르게 로드됩니다.

 

3-2. 캐시 가능한 메서드에는 어떤 것들이 있나요?

• 캐시 가능 메서드: GET, HEAD, POST, PATCH
  • POST와 PATCH는 데이터 변경이 되는 메서드로, 구현의 복잡성 혹은 유지의 어려움 때문에 잘 사용하지 않음
• 캐시 불가능 메서드: DELETE, PUT, OPTIONS, CONNECT

4. HTTP 메서드 한눈에 보기

Method	Safe	Idempotent	Cacheable
GET	O	O	YES
HEAD	O	O	YES
OPTIONS	O	O	No
TRACE	O	O	No
DELETE	-	O	No; invalidates cache
PUT	-	O	No; invalidates cache
POST	-	-	Sometimes
PATCH	-	O	Sometimes
CONNECT	-	-	No

 

 

---

참고

• 모든 개발자를 위한 HTTP 웹 기본 지식
• HTTP의 멱등성 · 안정성 · 캐시성 💯 완벽 이해하기
• HTTP Methods