HTTP Method, PUT과 PATCH의 차이점

(그림판ㅋㅋ)

0. 서론

HTTP Method를 다루게 된 계기:

 

RESTFul한 API 설계를 하기 위해 프로젝트를 리팩토링하는 과정에서...

요청의 행위를 표현하기 위해 HTTP Method를 잘 활용해야 한다는 점에 주목했다.

 

때문에 GET, POST, PUT, DELETE를 썼는데,

내용적으로 PUT보다 PATCH가 맞을 것 같다는 피드백이 있어서 이에 대해 조사해보았다.

 

1. PUT과 PATCH

PUT 정의:

HTTP PUT 메서드는 요청 페이로드를 사용해 새로운 리소스를 생성하거나, 대상 리소스를 나타내는 데이터를 대체한다.

PATCH 정의:

HTTP PATCH 메서드는 리소스의 부분적인 수정을 할 때 사용된다.

 

정의만으로 내가 알던 것과 다르고, 차이점도 드러나는 것 같다.

그래도 더 부연하자면,

PUT은 리소스 전체를 업데이트하는 것이고,

PATCH는 리소스의 일부만 업데이트 하는 것이다.

 

즉, 메서드는 PUT인데 request body에는 일부만 담아 보낸다면, 해당 일부를 제외한 부분은 null로 업데이트 되는 게 논리적으로 맞다는 말도 되고,

애초에 request body에 일부만 담아 보낼거라면 일부만 수정하겠다는 뜻 아닌가? 한다면 처음부터 PATCH 메서드로 보냈어야 하는 게 맞다.

 

또한 PATCH는 말그대로 일부를 수정하는 작업만 담당한다면, (생성의 역할은 하지 않는다)

PUT은 pk가 일치하는 리소스가 없다면 새로운 자원을 생성하는 역할을 하기도 한다.

 

 

2. 멱등성의 관점

이후 다른 포스팅에 추가적으로 HTTP Method의 멱등성에 관련해서도 다루겠지만,

PUT과 PATCH의 차이점을 가장 잘 나타내는 게 멱등성이라고 생각한다.

 

멱등성이란, 수학이나 전산학에서 연산의 한 성질을 나타내는 것으로, 연산을 여러 번 적용하더라도 결과가 달라지지 않는 성질을 말한다.

f( f(x) ) = f(x) for any x 라고도 표현할 수 있다.

 

HTTP의 멱등성이란,

동일한 요청을 한 번 보내는 것과 여러번 연속으로 보내는 것이 같은 효과를 가지고, 서버의 상태도 동일하게 남는 성질을 의미한다.

 

중요한 점은, 응답 상태 코드가 달라도 서버의 상태가 동일하면 된다는 점이다.

 

왜 멱등성이 나오냐면...

PUT은 멱등성을 가지지만, PATCH는 멱등성을 가지지 않아도 되기 때문이다.

 

2-1. PUT은 멱등성을 갖는다.

PUT은 말했듯이 리소스가 없으면 생성, 있으면 전체 업데이트이기 때문에,

이해하기 쉽게 말해 "특정 pk로 이 요청을 덮어쓴다"는 요청이다.

 

HTTP Method PUT의 스펙을 살펴보면,

PUT - HTTP | MDN

새로운 리소스를 생성하는 경우 201(Created)를 반환하고,

기존 리소스를 업데이트하는 경우 200(OK) or 204(No Content)를 반환하라고 한다.

즉, 예를 들어 같은 요청에 대해 처음에는 201을 반환했고, 두 번째에는 204를 반환했다고 하더라도,

응답 코드가 다르다고 해서 멱등성이 깨진 게 아니라, 서버의 상태가 동일하게 유지되기 때문에 멱등성을 만족한다고 보는 것이다.

 

2-2. PATCH는 멱등성을 갖지 않는다.

업데이트를 하는 메서드라는 관점에서 설계한다고 상상했을 때,

PATCH도 멱등성을 갖는거 아닌가? 하는 질문이 떠올랐다.

 

하지만 MDN에서 PATCH 메서드는 멱등성을 만족하지 않아도 된다고 말하고 있다.

"A PATCH is not necessarily idempotent, although it can be." - MDN web docs

즉, 할 수 있어도 안해도 된다는 건데, 안 하는거 어떻게 하지?

 

이런 요청이면 멱등성을 가지지 않아도 PATCH로 요청을 보낼 수 있다.

[ Posting 테이블의 posting_sn(기본키) = 5인 레코드의 조회수를 +1 하라 ] 는 요청이 그렇다.

 

예시를 들었으니 설명은 필요 없겠지?

PUT으로 저런 요청을 보내도 오류는 안나겠지만 멱등성을 지키라는 원칙에는 어긋나게 되는 셈이다.

 

 

3. 맺으며

사실 RESTFul한 API의 설계 규칙도 지키고, HTTP Method의 스펙(+멱등성)도 지키면서 설계를 하라니...

조금 버거울 수도 있지만,

 

개발을 할 때, 내가 코드를 짜는 중간에 누군가가 내 코드를 열람하더라도 무슨 의도인지 알면 좋긴 하니까?

 

그리고 아무래도 이런 규약이 있는 편이... 내가 언제 코딩을 하더라도 통일성있게 규칙적으로 깔끔하게 코드를 생산할 수 있지 않나... 싶은 측면에서 오히려 좋기도 한 것 같다.

 

또 이 글을 혹시 누가 찬찬히 읽어준다면... 다른 메서드의 스펙에 대해서도 궁금해할텐데, 다음 포스팅에 한꺼번에 정리해보겠다.