[REST API]Put VS Patch 예제로 이해해보자

HTTP Method에서 PUT PATCH는 수정에 사용되는데 명확하게 이해하고 있지 않은듯하여

정리해본다. 간단한 개념을 살펴보고 예제로 명확히 알아보자.

간단히 살펴보기

공식 RFC 문서 에서 PATCH에 대한 정보를 확인해보자.

• PUT: 전체 필드가 제공되어야 한다. 전체 필드를 수정한다.
  • 해당 Entity의 결과 값은 요청값과 항상 같다. (멱등성)
• PATCH: 부분 필드만 제공한다. 부분 필드를 수정한다.
  • 해당 Entity의 결과 값은 다를 수 있다.

멱등-성 冪等性 명사 수학 연산을 여러 번 적용하더라도 결괏값이 달라지지 않는 성질.

✔️ 여기서 Entity는 조회 대상 테이블에 대한 한 건의 row 데이터를 칭하는 것이다.

예제

특정 사용자의 나이를 바꾸는 예제를 PUT과 PATCH로 구분해서 알아보자.

PUT

PUT /users/1
// request body
{
  "id": 1,
  "name": "Sam Kim",
  "age": 30
  "email": "skwee357@newdomain.example",    // the email changed, yay!
  "city": "New York",
}

// result
{
  "id": 1,
  "name": "Sam Kim",
  "age": 30
  "email": "skwee357@newdomain.example",
  "city": "New York",
}

PATCH

PATCH /users/1
// request body
{"age": 30}

// result
{
	"id": 1,
	"name": ??,
	"age": 30,
	"email": ??,
  "city": ??,
}

주요한 차이점은 역시 Request Body에 전체 필드를 제공하냐 부분 필드를 제공하냐 이다.

PATCH에 대한 처리는 Server쪽 처리에 따라 다를수 있지만 명시된 필드만 수정되는것이 일반적일 것이다. 물론 다른 필드에 대한 처리가 이루어질 수도 있다.

멱등성

위의 예제에서 확인 하였듯이, 수정 대상이 되는 entity의 결과값은 PUT인 경우 항상 요청대로 변경이 된다. 하지만 PATCH의 경우는 부분 필드만 수정을 보장하기 때문에 나머지 필드에 대해서는 알 수 없으므로 Entity의 결과값은 알 수 없다.

왜 그게 중요한데?

PUT으로 요청을 보낼 때는 멱등성을 보장하기 때문에 요청에 대한 결과값을 Cache 하여도 문제가 없지만, PATCH의 경우는 그렇지 않다는 것을 알 수 있다..

이는 HTTP Cache 설정 차이에 더해서 PUT으로 수정되는 Entity는 Client에서 서버 반환값과 상관없이 수정한 대로 그대로 사용하여도 된다는 의미이다.

실제 적용에 대한 견해

현재 프로젝트 개발 시 PUT 을 사용하는 경우가 있을까?

일단 대답은 NO 이다. 현재까진 전체 필드를 수정할 일은 없었다.

왜냐하면 모든 필드에는 수정시간(updateAt), 수정자(updateBy) 필드가 있었기 때문인데,

이는 Client가 모든 필드에 대한 수정을 담당하지 않는 것을 뜻하며, PUT이 아닌 PATCH를

사용하여야 했다. 

마치며

아마 대부분의 프로젝트에서도 Client에서 모든 필드에 대한 수정을 하지 않고 일부 수정은 서버에서 이루어지는 경우가 빈번히 있을 것이다.  또한 조회 시 서버로 부터 받은 Entity 데이터가 모든 필드를 포함하지 않는 경우도 많을 것이다.

그렇기에 PATCH 가 PUT 보다 더 많이 사용되지 않을 까 생각한다.

물론 PUT을 통해서 전체 필드를 수정해도 되는 경우라면 응답 Cache를 활용할 수 있는 PUT을 사용하는 것이

바람직하겠다.

다른 분들도 핵심 키워드인 필드, 멱등성 두 가지를 기준으로 명확하게 체득할 수 있기를 바란다.