본문 바로가기

Develop

PUT 와 PATCH 차이

같은 듯 같지 않은 HTTP 수정 method

들어가며

이 질문을 생각하게 된 시작은 이렇습니다.

일반적으로 데이터를 관리하는 기본 연산을 CRUD로 부르잖아요. 각 연산을 하나씩 제가 알고 있는 http method 에 연결하다보니 이런 질문이 떠오르게 됬습니다.

Http 수정 method PATCH, PUT는 같은거야 다른거야?

  • Create - POST
  • Read - GET
  • UPDATE - PUT, PATCH
  • DELETE - DELETE

특이하게도 세번째에 위치한 수정을 위한 연산은 두 개의 method가 대응이 됩니다. 어떻게 이런 일관되지 않은 구성을 가지게 되었을까요?

본론

항상 그렇듯이 stack overflow에서 인기있는 답을 찾아 보았습니다. 답에 대한 voting 숫자가 1000이 넘네요. (이정도 숫자면 무비판적으로 읽어도 될 수준이군요.)

비교

  DB operations HTTP method DRF ModelViewSet action
생성 CREATE POST create()
읽기 READ GET retrieve() list()
수정 UPDATE PUT PATCH update() partial_update()
삭제 DELETE DELETE destroy()

예시

특정 자원이 가지는 속성을 변경할 때 두 method 모두 사용 가능합니다. 단 차이가 있는데요, PATCH 경우 변경하고자 하는 속성의 키와 값만 전달하면 되지만, PUT의 경우는 그 자원이 가지는 모든 속성 값을 전달해야 한다. 예를 들어보겠습니다.

Car
 - color
 - price
PUT PATCH
/car/10/ {"color": "blue", "price": 200} /car/10/ {"color": "blue"} 또는 {"price": 200} 또는 {"color": "blue", "price": 200}

위와 같이 PATCH 요청시에는 부분/전체 속성을 body에 실어 보낼 수 있습니다만, PUT의 경우는 반드시 모든 속성 값을 포함해야 요청이 성공합니다.

개인적으로는 PUT보다 PATCH가 더 유연해 보여 자주 사용합니다. PATCH가 PUT기능을 포함하고 있는 것 처럼 보이는데, PUT이 왜 필요한지는 좀 더 생각을 해 보아야겠습니다.

요약

  • PUT: 대상 리소스의 모든 속성을 수정한다.
  • PATCH: 대상 리소스의 일부 속성만 수정한다.

질문

  • 대부분의 상황에서 PATCH 만 사용한다면 수정 작업을 요청할 수 있다. 그럼에도 PUT 가 표준으로 남아있는 이유는?

마무리

매번 이직을 할 때마다 PUT, PATCH를 위 의미에 맞게끔 사용하는 개발팀은 흔치 않습니다. 개인적으로는 PATCH를 선호하지만, 그렇다고 이미 PUT 방식으로 개발된 내용을 수정하는 것은 어려운 작업입니다. Backend 코드 뿐 아니라 Frontend 코드도 함께 변경이 필요할 뿐 아니라 지금 상태에서도 서비스는 문제 없이 잘 작동하는데 수정작업중에 이슈라도 발생한다면 남는 장사가 아니기 때문입니다.

새롭게 팀빌딩을 해서 처음부터 프로젝트를 시작하게 되는 상황에서는 PATCH 방식으로 진행해 보고 싶네요. 여기까지 http update method에 대한 차이점을 정리해 보았습니다. 제가 놓친 내용 또는 첨하고자 하시는 내용 있다면 덧글 부탁드립니다.

참고

https://www.django-rest-framework.org/api-guide/viewsets/

https://blog.naver.com/dyno_tyno/221465564795

https://stackoverflow.com/questions/28459418/use-of-put-vs-patch-methods-in-rest-api-real-life-scenarios

반응형