[HTTP] HTTP Method 속성 (안전성, 멱등성, 캐시 가능성)

HTTP Method 에는 각각의 여러 속성이 있다.
어떤 메서드로 서버에 요청했는지에 따라 API 설계, 복구 메커니즘, 캐시 최적화 등 설계의 로직에 영향을 준다.
HTTP 메서드의 속성엔 대표적으로 안전성, 멱등성, 캐시 가능성이 있다.

안전성이란?

HTTP Method가 서버의 상태를 바꾸지 않으면 그 메서드가 안전하다고 할 수 있다. 즉, 읽는 작업만 수행하는 메서드가 안전하다. 따라서 자주 볼 수 있는 HTTP Method 중에서는 GET, HEAD, OPTIONS 가 안전성을 가진다.

멱등성이란?

멱등이란 연산을 여러 번 적용하더라도 결괏값이 달라지지 않는 일을 말한다.

이 정의를 HTTP의 멱등성에 대입해보자. 요청을 한 번 호출하든, 여러 번 호출하든 그 결과가 같음을 말한다. 즉, 동일한 요청을 한 번 보내는 것과 여러번 연속으로 보내는 것이 같은 효과를 가지고, 서버의 상태도 동일하게 남을 때 해당 HTTP Method가 멱등성을 가진다고 할 수 있다.

GET은 여러 번 호출해도 같은 결과가 돌아오며, 리소스에 변화를 주지도 않는다. PUT은 여러 번 호출해도 매번 같은 리소스로 업데이트되기 때문에 결과가 달라지지 않는다. 따라서 GET, PUT 처럼 리소스를 조회하거나 대체하는 메서드는 멱등성을 가진다. DELETE 또한 여러 번 호출해도 삭제된 리소스에 대한 결과가 달라지진 않는다.

이처럼 GET, PUT, DELETE, HEAD, OPTIONS, TRACE와 같은 HTTP Method가 멱등성을 가진다.

안전성과 멱등성의 차이?

요청을 한 번 호출하든 여러 번 호출하든 리소스에 수정이 발생하지 않는 것이 안전성을 가지는 것이며,
리소스에 수정이 발생한다해도 메서드를 여러 번 실행한 결과가 한 번 실행한 결과와 같다면 멱등성을 가진다.

멱등성을 API 관점에서 본다면 멱등한 API는 두 번 이상 요청해도 결과는 처음 요청과 똑같이 돌아온다. 단순히 돌아온 값 뿐만 아니라 서버 상태(DB)에도 영향을 미치지 않는다. 이처럼 시스템에 의도하지 않은 문제를 일으키지 않고 요청을 재시도할 수 있기 때문에 멱등성은 결함없고 안전한 API를 만드는데 중요하다.

이처럼 멱등한 API인지 확인하려면 확인하는 방법도 있다. 자세한 내용은 다음 링크를 참고하면 좋을 듯하다.

https://www.tosspayments.com/blog/articles/21448

안전성이 보장된 메서드는 리소스를 변경하지 않기에 동시에 멱등성도 보장된다. 하지만 멱등성을 지닌 메서드가 항상 안전성을 보장하진 않는다.

PATCH의 멱등성?

PUT은 해당 리소스를 완전히 교체하기 때문에 멱등이라 할 수 있다.
하지만 PATCH는 HTTP 스펙상 구현 방법에 제한이 없고, 요청에 꼭 덮어 쓸 데이터가 있을 필요가 없다. 따라서 PATCH는 기본적으로 멱등성을 가지지 않는 메서드이며, 멱등으로 설계할 수도, 멱등이 아니게 설계할 수도 있다.

캐시 가능성이란?

응답 결과 리소스를 캐싱해서 효율적으로 사용할 수 있는가에 대한 여부이다.

캐시가 꼭 운영체제, 서버에만 있는 것이 아닌 브라우저 자체도 하나의 소프트웨어라 캐시 공간이 있다. 캐시 공간은 클라이언트가 서버에 한 번 요청했던 데이터에 대해 매 요청마다 다시 전송할 필요 없도록 브라우저에서 임시적으로 보관하고 있는 장소이다.

따라서 캐싱이 가능한 HTTP Method는 빠르게 결과 값을 받을 수 있다.

스펙상은 GET, HEAD, POST, PATCH 메서드가 캐시 가능성을 가지고 있다.

하지만 POST, PATCH와 같은 메서드들은 캐싱하기엔 body 데이터가 꽤 크기 때문에 실제로는 GET과 HEAD 메서드 정도를 캐시로 사용한다.