20230106 TIL PUT인가 PATCH인가 그것이 고민이로다

https://media.licdn.com/dms/image/C4D12AQH9EDkm0IlSTg/article-cover_image-shrink_600_2000/0/1622058139473?e=2147483647&v=beta&t=M66G4zvu-ZyOUDtN1RP_vuoFiKEJjehgG5n61f0EdrM

리소스의 일부만 수정할 때 PATCH를 사용하고, 전체를 수정할 때 PUT을 쓴다라는 것은 알고 있었다.
그런데 이 사실만으로는 PUT을 쓸지 PATCH를 쓸지 결정을 하기가 어려웠다.
왜냐하면 나머지 정보도 같이 주면 결국 PATCH도 PUT과 다른 것이 없다고 생각했기 때문이다.

PUT과 PATCH를 구분하는 또 한 가지 기준점은 멱등성이다.
멱등성은 몇 번을 반복해서 동일한 과정을 반복해도 같은 결과가 나오는 특성이다.
PUT은 리소스를 완전히 교체해버리는 경우에 사용되고, 항상 멱등하다.
PATCH는 멱등하거나 멱등하지 않게 설계할 수 있다.

질문 추천하기 기능을 만들면서 하게 된 고민이었다.
질문을 추천하면 추천한 사람의 token을 전송하게 되고, 이를 바탕으로 id를 찾아서
질문을 추천한 사람들의 id로 이뤄진 배열에 추가된다.
body에 질문리소스 전체값을 보내지 않을 것이기 때문에 PATCH를 쓰면 된다는 판단을 내릴 수 있었다.
그리고, 질문 추천 및 추천 취소를 할 수 있어야 하는데,
나는 동일한 PATCH메서드를 호출할 때마다 서버 내부에서 id가 포함되었는지 여부에 따라 toggle이 되게 구현을 했는데,
이런 경우 PATCH메서드 API에 body에 {like:true}, {like:false}등을 넣어서 보내는 것이 RESTful한 방식이라고 한다.

이번 고민을 통해 어떻게 하면 조금 더 RESTful한 API를 만들 수 있는지 알 수 있었던 것 같다.
작업을 진행하면서 고민이 되는 부분들은 꼭 찾아보도록 하자.