API 설계를 하면서 고민 해볼만한 이야기

백엔드 개발을 하면서 다들 한번쯤은 클라이언트들과의 통신을 위해서 API를 개발합니다

 

우리 백엔드 개발자는 좋은 API를 개발하기위해서 Rest API, Graph API 등 여러 API에 대한 내용을 알아보면서 해당 통신규약이 정의하는 우리 프로토콜에서는 이런 방식으로 개발하는게 좋아!! 라는 글을 읽어가면서 Rest ful하게 API를 만들어 나갑니다

 

 

오늘 좋은 경험을 겪었던 예시로 한가지 썰(?)을 풀어볼까 합니다

Reddit에서 볼수있는 Title

여러분들이 Reddit처럼 한가지의 post에 like, unlike를 할수있는 API를 개발하려고 합니다(간단한 기능이죠?)

 

네 딱히 어려운 내용은 크게없습니다

 

한명의 유저는 하나의 포스트에만 like, unlike, none 총 3가지의 상태만 가질수 있으니

이번 포스팅에서는 Rest API에 관련해서 작성해볼까 합니다

 

1. 투표를 하는 API

POST /posts/:postId/votes

body: { userId: number } 

 

2. 투표를 수정하는 API

PUT /posts/:postId/votes

body: { userId: number, type: like or unlike } 

 

3. 진행했던 투표를 수정하는 API

DELETE /posts/:postId/votes?userId: number

 

이렇게 총 3가지의 API를 생성한다고 저는 처음에 가정을 했었습니다

 

내가 투표를 처음 부터 할수도, 투표를 수정, 삭제 기능 이렇게 총 3가지의 기능이 들어가 있으니 API를 3가지로 분리하고 나머지는 클라이언트가 알아서 판단해서 API 호출하면 되겠네!

 

다만 Reddit에서는 하나의 Post API에서 vote의 관련된 모든 기능을 처리하고 direction값으로 -1, 0, 1의 값으로 API를 처리하는게 잠깐 이상하다고 생각만하고 Pull Request를 올렸었는데

 

Reddit에서의 vote관련된 API

결과는 어떻게 됬을까요??

 

네... Reject을 받았습니다

 

물론 제가 생각했던 방식과 다르게 생각하실수도 있습니다

 

클라이언트의 입장과 백엔드 입장에서의 API를 서로 생각해보면 저는 이렇게 나뉜다고 생각합니다

 

- 백엔드

• 새로운 Vote를 하는 POST API
• 기존의 Vote Type을 새로운것으로 바꾸는 POST API
• Vote했던것을 취소하는 DELETE API

그러나 클라이언트 입장에서보면 모든 API콜은 결국 맨 마지막의 action만 Update 되기를 바랍니다

 

즉슨 Vote Type을 보고 여러 API중 하나를 선택하는것이 아닌 하나의 PUT API에 본인이 원하는 Type을 보내고 해당하는 API로

Update 되기를 바라는것입니다 

 

조금만 생각해보면 한명의 User가 두개의 기기에서 하나의 기기에만 DELETE를 하고 다른 기기로 event가 가기전에 다른 기기에서도 DELETE API호출을 하면 404 NOT EXISTS에러가 나오겠죠

 

그게 과연 맞는 상황일까요?

 

백엔드의 입장으로써만 보면 그렇게 틀린 대답은 아닙니다 DELETE의 멱등성도 지키고 실제로 Vote Resource또한 없으니깐 말이죠

 

그러나 결국 REST도 통신규약입니다

 

클라이언트와 더 좋은, 깔끔한 방식으로 통신을 하기위한 규칙인데 너무 한쪽의 입장에서만 생각하는것이 아닌 양쪽 모두의 상황을 볼줄아는 생각을 좀 더 생각해봐야겠다는 중요한 시간이 되었습니다ㅠㅠ