작성
·
6K
22
패치의 경우 멱등성을 갖지 않는 이유가 무엇인가요? 외부 요인에 의해 값이 변경되지 않는 이상 항상 같은 결과를 가져오는 것 아닌가요..?
답변 2
88
안녕하세요. kaka님
PUT은 해당 리소스를 완전히 교체해 버리기 때문에 멱등입니다.
PATCH는 멱등으로 설계할 수도 있지만, 멱등이 아니게도 설계할 수 있습니다.
예를들어서 다음과 같은 경우는 PATCH 이지만 멱등입니다.
{ name: "kim"}
반면에 다음과 같은 경우는 PATCH 이지만 멱등이 아닙니다.
예를 들어서 한번 호출할 때 마다 나이를 10 더하는 식으로 변경하고 싶다고 가정하겠습니다.
PATCH는 멱등이 아니기 때문에 다음과 같이 특정 부분을 추가로 더하거나 하는 식으로 설계해도 됩니다. 물론 이 경우 서버에서 operation add가 어떤 의미인지 알 수 있어야 합니다.
{ "operation": "add", "age": 10"}
이렇게 하면 2번 호출하면 +10 + 10이 되어 버려서 먹등이 아닙니다.
정리해드리면 PATCH는 리소스의 특정 부분을 변경하는데, 이 변경 방식이 멱등이어도 되고, 멱등이 아니어도 됩니다.
도움이 되셨길 바래요^^
2
PUT도 마찬가지 아닌가요? 호출 될 때마다 count가 증가하는 PUT메서드가 있다면 해당 PUT요청을 호출할때마다 count값이 변하니 PUT도 멱등이 아닐 수 있지 않나요?
제가 제대로 이해한게 맞다면, put은 전체 데이터를 넣는 용도로 사용하는 것이고,
이 경우 그 데이터의 값을 그대로 넘기게 되는 것이며,
데이터를 넣는다는 뜻은 그전에 무엇이 있던 말던 상관없이 그냥 넣겠다는 의미로 이해했습니다.
patch의 경우에는 데이터를 부분적으로 변경하는 용도로 사용하는 것이라고 이해했습니다.
데이터를 넣는것과 달리, 변경은 기존의 어떠한 상태에서 어떠한 상태로 변경하는 것이기에
두가지로 갈리는 것이라고 이해했습니다.
1. 기존에 있던 값과 상관 없이 그냥 이 데이터를 넣어서 변경해줘
2. 기존에 있던 값에 대해 이런 연산을 진행해서 이 데이터를 통해 데이터를 변경해줘
2번의 경우가 멱등이 아니게 되는 경우를 유발하는 경우이며, 1번 2번 모두 그 메서드의 원래 목적대로 사용한게 맞기에 멱등이 아니게 되는 정상적인 경로라고 이해했습니다.
반면 put의 경우 원래 정상 목적자체가 그냥 데이터를 넣어달라는 요청이기에, 정상적으로 사용한다면 멱등이며, patch처럼 사용을 했다면, 그 목적대로 사용하지 않았기 때문에 멱등이 되지 않을 수 있으나,
잘못 사용한 것에 대해서는 고려하지 않는 것 같습니다.
음.. 제가 이해한 것을 바탕으로 다른 예시를 들자면
get메서드는 파라미터를 전송할 수 있습니다.
이는 데이터를 변경하는 용도가 아니라 조회를 위해 있는거죠?
그런데 이 파라미터를 받아서 서버가 데이터를 처리해서 내부 데이터를 변경했다고 하면
이는 멱등이 되지 않습니다.
아마 이 멱등같은 조건을 파악하는 건 http메서드를 원래 목적에 올바르게 사용한 경우라고 이해했어요.
혹시 제가 이해한게 틀렸다면 누가 댓글로 더 정확하게 알려주세요. - 저도 배우고 싶습니다.
감사합니다