▶들어가며
개발을 하고 API 명세서를 짜다보면
“아 이거 PUT 써야됨 아니면 PATCH 써야됨??”
이런 순간이 올것이다.
오늘 한번 알아보자.
우선 PUT과 PATCH의 정의에 대해서 알아보자.
▶ PUT 과 PATCH의 정의
HTTP PUT 메서드는 요청 페이로드를 사용해
새로운 리소스를 생성하거나,
대상 리소스를 나타내는 데이터를 대체한다.
HTTP PATCH 메소드는 리소스의
부분적인 수정을 할 때에 사용된다.
정의만 봐도 어느정도 느낌이 온다.
그 느낌을 구체화 해보자.
우리는 3가지 예시를 통해 PUT과 PATCH의 차이에 대해서 알아볼것이다.
▶ 차이점
▷ UPDATE 방식의 차이
PUT
아래와 같은 리소스가 있다.
id | name | money |
1 | 김씨 | 5000 |
2 | 이씨 | 7000 |
3 | 박씨 | 3000 |
이 리소스에 id 값이 3인 데이터한테 두가지의 PUT 요청을 보내보자.
1.
PUT /user/3
{
"name": "박씨",
"money": 10000
}
2.
PUT /user/3
{
"money": 10000
}
이 PUT 요청에 대한 결과는 다음과 같다.
결과1.
id | name | money |
1 | 김씨 | 5000 |
2 | 이씨 | 7000 |
3 | 박씨 | 10000 |
결과2.
id | name | money |
1 | 김씨 | 5000 |
2 | 이씨 | 7000 |
3 | null | 10000 |
즉, 보내지 않은 값은 null로 대체된다.
PUT의 정의처럼 데이터를 대체하는 것이다.
PATCH
이번에는 똑같은 요청인데 HTTP 메소드를 PATCH로 바꿔보자.
1.
PATCH /user/3
{
"name": "박씨",
"money": 10000
}
2.
PATCH /user/3
{
"money": 10000
}
이 둘의 결과는 다음과 같다.
결과1.
id | name | money |
1 | 김씨 | 5000 |
2 | 이씨 | 7000 |
3 | 박씨 | 10000 |
결과2.
id | name | money |
1 | 김씨 | 5000 |
2 | 이씨 | 7000 |
3 | 박씨 | 10000 |
즉, 보내지 않은 값은 그 전의 값 그대로 유지되고 있다.
▷ 요청한 URI에 자원이 존재하지 않을 때
PUT
새로운 자원을 생성한다.
id | name | money |
1 | 김씨 | 5000 |
2 | 이씨 | 7000 |
3 | 박씨 | 3000 |
위에와 똑같은 리소스에 이번에는
PUT /user/4
{
name : 지씨
money : 3500
}
이런 요청을 보내보면
그 결과는
id | name | money |
1 | 김씨 | 5000 |
2 | 이씨 | 7000 |
3 | 박씨 | 3000 |
4 | 지씨 | 3500 |
이렇게 새로운 자원을 생성한다.
PATCH
새로운 자원을 생성하지 않는다.
id | name | money |
1 | 김씨 | 5000 |
2 | 이씨 | 7000 |
3 | 박씨 | 3000 |
위에와 똑같은 예시로
PATCH /user/4
{
name : 지씨
money : 3500
}
이렇게 메소드만 바꿔서 요청을 보내보면
id | name | money |
1 | 김씨 | 5000 |
2 | 이씨 | 7000 |
3 | 박씨 | 3000 |
결과로는 아무것도 바뀌지 않는다.
서버는 오류를 응답으로 보낼뿐이다.
▷ 멱등성 관점
우선 멱등성이란?
- 동일한 요청을 한번 보내는 것과 여러번 연속으로 보내는 것이 같은 효과를 지녀야함.
- 서버의 상태도 동일하게 남아야함.
- 위 2가지를 만족시키는 HTTP 메서드를 멱등성을 가졌다고 말한다.
즉, 서버로 요청을 여러번 날리는 행위와 한번 날리는 행위가 같은 결과를 내면 멱등성이 있다고 할 수 있다.
PATCH - HTTP | MDN
위 MDN 문서 등을 보면
PUT은 멱등성을 가지지만, PATCH는 멱등성을 가지지 않는다고 적혀있다.
그런데 위에 작성한 예시들을 보면 두 메소드 모두 멱등성이 있는 것 처럼 작동한다.
그렇다면 PATCH는 왜 멱등성을 가지지 않는다고 하는 것일까?
예를 들어
PATCH /user/4
{
"$increment": {
"money": 1000
}
}
이 요청이 보내질 때마다 id=4인 사용자의 money 필드는 1000씩 증가한다.
따라서 같은 요청을 여러 번 보내면 결과가 달라지므로,
PATCH 메서드는 멱등성을 가지지 않는다.
이 경우 PATCH 요청이 보내질 때 마다
id=4인 데이터의 money가 1000씩 늘어나므로
PATCH 메소드는 멱등성을 보장하지 않는다는 것이다.
이런식으로 PATCH 메소드를 사용하는건 못봤지만…
따라서 PATCH 메소드는 API를 어떻게 구현하냐에 따라서 멱등성을 보장할 수도 있고 아닐 수도 있다는 것이다.
▶ 정리 및 내 생각
내 생각에는 마지막 예시인 멱등성? 그거는 PUT과 PATCH를 구분하여 사용하는 큰 이유는 아닌 것 같다.
그래서 정리를 해보자면
- PUT 메서드:
- 리소스를 전체적으로 업데이트할 때 사용한다.
- 요청 본문에 모든 필드를 포함해야 하며, 전송되지 않은 필드는 null로 처리된다.
- 요청한 URI에 자원이 존재하지 않을 때 새로운 자원을 생성한다.
- PATCH 메서드:
- 리소스의 일부 필드를 업데이트할 때 사용한다.
- 요청 본문에 포함되지 않은 필드는 기존 값을 유지한다.
- 요청한 URI에 자원이 존재하지 않을 때 서버로 오류를 응답한다.
이렇게 두가지의 메소드를 구분하여 사용하면 좋을 것 같다.