REST – PUT vs POST

42월드 팀원이 기존 api를 살펴보는 중 좋아요 api의 메소드에 대한 이야기가 나왔다. 좋아요에 어떤 의견들이 나왔는지 앞서, 좋아요 기능이 어떻게 되어있는지 알아보자.

POST /reactions/articles/{id}

좋아요 버튼을 누를 시 동작하는 api

• 좋아요를 누를 경우 좋아요 수를 + 1 증가시킨다
• 좋아요가 이미 되어 있는 경우 좋아요 수를 -1 감소시킨다

그런데 여기서 좋아요를 감소시키는 경우, reactionArticleRepository의 좋아요 데이터를 삭제 시키는데 POST가 맞을까?

의견 1
생성과 삭제 둘 다 있으니 PUT이 조금 더 어울릴 것 같다

의견 2
생성과 삭제 둘 다 하니 Restful하지 않다. 아예 post / delete 분리되어야 하지 않나?

-> 빠르게 좋아요를 누를 경우 post-delete-post-delete 순으로 api를 보내야 하는데 실제 지연이 생기면서 post-delete-delete-post으로 동작할 수 있다.

나도 생성/삭제 나누는게 맞다고 생각하는데 저렇게 순서가 나눠지는 경우 문제가 생길 수 있다고 하니 보류했다. -> 멘토님께 질문 드릴 예정

여기서 내가 몰랐던 부분

여기서 POST와 PUT중 어떤 걸 사용해야 하는지 이야기를 나누고 있는 와중에 POST와 PUT이 어떤 차이가 있는지 한번 더 찾아보고 싶었다. 대략적으로 POST는 생성, PUT은 업데이트로 알고 있었지만 조금 더 알아보자.

POST vs PUT

참고 도서 : HTTP 완벽 가이드 3장

POST
POST 메서드는 서버에 입력 데이터를 전송하기 위해 설계되었다.
PUT
PUT 메서드는 서버가 요청의 본문을 가지고 요청 url의 이름대로 새 문서를 만들거나, 이미 URL이 존재한다면 본문을 사용해서 교체한다.

각주)
POST는 서버에 데이터를 보내기 위해 사용한다.
PUT은 서버에 있는 리소스에 데이터를 입력하기 위해 사용한다.

참고 링크: REST – PUT vs POST

POST

• 리소스를 새로 생성할 때 사용한다
• 멱등하지 않다
• N번 반복한다면 N개의 다른 리소스가 만들어진다
• request url에 정의된 리소스 하위에 생성하고 싶을 때 사용한다 EX alticles
• 따라서 request url는 리소스의 Entity를 나타내는 Collection URL이어야 한다

PUT

• 업데이트에 사용한다
• 만약 이미 있는 데이터라면 업데이트를 하고 아니라면 생성을 한다
• 기존 Collection URLalticles 에 더해 해당 리소스의 Resource Identifier를 나타내줘야 한다 EX alticles/id
• 멱등해야 한다
• 여러번 반복하더라도 한번 보낸 결과와 같아야 한다

Example

GET 	/device-management/devices       : Get all devices
POST 	/device-management/devices       : Create a new device

GET 	/device-management/devices/{id}   : Get the device information identified by "id"
PUT 	/device-management/devices/{id}   : Update the device information identified by "id"
DELETE	/device-management/devices/{id}   : Delete device by "id"

다시 돌아와서

좋아요는 어떨까? 좋아요를 누를 시

• 좋아요 Collection 하위에 리소스들이 만들어진다. (누가 누구의 게시글에 좋아요를 했는지)
• 좋아요 하나의 값을 업데이트 하는 것도 아니라

확실히 POST로 보인다.