먼저PUT 과 PATCH 는 HTTP의 메소드이다. 그러나 이 두개를 비교하기전에 멱등성에 대해서 알아야한다.
Q. 그래서 멱등성이 무엇인가요?
A. 어떤 대상에 같은 연산을 여러번 적용해도 결과가 달라지지 않는 성질이다.
즉 코드로 와닿게 느끼자면 다음과 같이 볼수 있을것 같다.
public Idemp(int num) {
return num;
}즉 아무리 Idemp 함수에 숫자를 계속 넣고 연산을 하여도 같은 값이 반복된다.
그럼 이제 PATCH와 PUT을 비교해보자.
둘다 자원을 수정하는 용도로 사용한다는 점이 같다. 즉 단순히 보자면 둘다 수정하는거 아니야? 라고 볼수있다.
RestAPI 를 작성하다보면 그 두 메소드의 차이를 실감하기 어려워 종종 ' PUT을 쓰는 Method 에 PATCH로 대체해서 똑같이 보내면 되는거아니야?' 라고 생각해왔다.
왠만하면 되는걸로 알고있지만 그렇다고 서로가 대체제의 역할이 아니다.
간단히 얘기하자면 효율을 그렇게 따지는 개발자들이 굳이 대체제 역할을 하는데 머하러 2개씩이나 만들까? 라고 생각하면 편하다.
PUT
일단 의미상으로 PUT의 경우 Payload에 있는 자원으로 전부 수정하고 대체하는 역할을 해준다.
요청 URI 에 자원이 존재하지 않는다면 새로운 자원으로 저장해주고 201을 Return을 받을수 있다.
요청 URI 에 자원이 존재하는 경우 Payload 에 있는 정보를 이용하여 새로운 자원을 만들어 대체해준다. 또한 200 or 204의 값을 Return 해준다.
즉 PUT의 있는 Payload가지고 수정하려는 자원의 전체 상태를 나타낼수 있어야 한다는 점이 가장 중요하다.
또한 일부가 불완전하게 전달해준다면 => null 값으로 들어가게된다.
즉 필드 A,B,C가 있는데 A,C의 정보만 PUT으로 준다면 B의 값은 Null 값으로 들어가게된다.
PATCH
일단 의미상으로 PATCH의 경우 Payload에 있는 자원으로 일부분을 수정하는 역할을 해준다.
즉 PUT 과 달리 수정하려는 자원의 전체 상태를 몰라도 일부분을 수정 할수 있다는 점이 PUT의 차이로 볼수 있다.
또한 일부가 불완전하게 전달을 받아도 전혀 건들지 않는다.
즉 필드 A,B,C가 있는데 A,C의 정보만 PATCH로 준다면 B의 값에는 아무 영향을 끼치지 못한다.
자 이제 멱등성을 따져가며 둘을 비교해보자.
들어 가기전 아래와 같은 부분을 인지하자.
※ 멱등성을 갖는 메소드가 서버의 상태를 변경하지 않는것이 아니며 멱등성을 갖는 메소드도 서버의 상태를 변경할수 있으며 핵심은 해당 요청을 반복하여 했을때 항상 같은 응답을 Return해주는가 이다.
PUT
항상 전체를 통으로 바꾸어 버리기 때문에 멱등성이 보장된다고 볼수있다.
앞서 나온 예시를 다시 인용하자면 필드 A,B,C가 있는데 A,C의 정보만 PUT으로 준다면 B의 값은 Null 값으로 들어가게된다.
그리고 이러한 메소드를 계속 호출을 하여도 계속 " A,C의 정보 + B의 널값 " 으로 들어오게 된다.
PATCH
일부분을 수정해주기 때문에 항상 멱등성이 보장 된다고 볼수 없다.
그러나 앞서 나온 예시를 다시 인용하자면 필드 A,B,C가 있는데 A,C의 정보만 PATCH로 준다면 B의 값에는 아무 영향을 끼치지 못한다.
그리고 이러한 메소드를 계속 호출하여도 계속 "A,C의 정보 + B의 고정된 정보" 로 서버의 상태는 계속 유지가 된다.
그러나 PATCH의 일부분만 수정하는 특성을 따져서 특정 부분을 추가 혹은 더하는 식으로 설계가 가능하다.
그래서 PATCH의 특성을 이용하여 서버통신프로그램을 작성하였고 마침 주제를 일정 버튼을 누르면 서버로부터 PATCH를 호출하여 절반을 만드는 프로그램으로 버튼을 누르면 누를 수록 절반의 값을 만드는 코드를 작성한다고 생각해보자.
그래서 Payload에 연산식 과 연산 숫자 를 다음과 같이 설정하였다.
{
Operation : "/"
num1 : "2"
}그러면 시작 숫자가 100이라고 생각해보면
1번 누를때는 50 그리고 2번 누를때는 25.. 그리고 N번 누르면 100 * (0.5)^N 의 값이 된다.
여기서 중요한건 이 식이 아니라 매번 누를때마다 값이 바뀐다는점이 중요하다.
즉 PATCH 메소드의 경우 멱등성 보장 받게 설계를 할수 있지만 항상 보장을 받을수 있는가? 라고 물어본다면 답은 X이다.
추가적인부분..
추가적인 부분 즉 메소드의 안전성 그리고 HTTP 메소드 중에서 어떠한것이 안전하고 어떠한 부분이 멱등성이 지켜지고 이러한 부분에 대해서는 다음포스팅에 기록을 하였으니 "여기" 서 확인 하면 된다.