m2m 관계의 api endpoint 설계 in rest api와 의사소통

Question

유튜브처럼 동영상에 좋아요를 누르는 것을 구현하기위한 예시입니다.ResourcesVideoUserLikeRelation (Video와 User의 m2m관계)위와 같이 Video, User 리소스, 그리고 Video와 User의 like 관계 정보를 저장하는 LikeRelation 리소스 총 3개가 있습니다.Endpointscreate와 delete api를 만들고자할 때 두 가지 방법을 생각했습니다.첫번 째 방법create: [POST] /user/{user_id}/like-relation/request data: {video_id: int}response: {like_relation_id: int}delete: [DELETE] /user/{user_id}/like-relation/{like_relation_id}/LikeRelation을 하나의 리소스로 생각하여 endpoint에 명시적으로 표시하여 생성 삭제합니다.두번 째 방법create: [POST] /user/{user_id}/like/request data: {video_id: int}delete: [POST] /user/{user_id}/like-cancle/request data: {video_id: int}like, like-cancle 라는 동작을 endpoint에 명시하고 요청하여 생성 삭제합니다.(두 방법은 api interface만 다르고 db 및 내부 동작은 같습니다.)선택resource create: [POST] /resource-name/resource delete: [DELETE] /resource-name/{resource_id}/전 rest api에서 위와 같은 패턴으로 resource를 생성 삭제한다고 이해했습니다.LikeRelation 또한 하나의 resource로 취급하고 같은 패턴으로 생성 삭제하는 것이 일관되다고 생각했습니다그래서 첫번 째 방법을 선택하고 개발하였습니다.실제도 더 많은 방법이 있을 수 있고, 어느 방법이 옳다라고 강요할 수 없는 부분이라 생각했습니다.그저 개발하는 당사자가 조금 더 납득되는 방법으로 선택하는 것이 좋다고 생각했습니다.논쟁요즘 저는 다른 개발자와 논쟁을 벌이는 일이 많아졌습니다.이 논쟁의 흐름은 아래와 같습니다.저: api 스팩 설계 및 공유저: api 개발 완료상대: 프론트 개발 진행상대: api 수정 요청논쟁api 수정 요청의 근거는 대략 아래와 같습니다.불필요한 패턴이다. 이상한 패턴이다.프론트에서 해야할 작업이 많아진다.코드가 지저분해진다.저의 의견설계 방법에 대해서는 틀렸다고 생각하지 않는다.자신의 기준에 맞지 않다고 잘못된 것은 아니다.저도 충분히 고민하여 선택한 것이고, 스팩을 공유하였다.api 개발 전 스팩에대해 논의할 시간이 충분했지만, 전혀 의견이 없었다.제가 프론트에게 마땅히 해줘야만 하는 일은 페이지 개발에 필요한 api 제공이라고 생각합니다.구조적으로 불가능한(데이터 누락 등..) 경우 당연하게 요구할 수 있지만.그 이외의 것(api 설계, api 퍼포먼스 등..)은 부수적인 것이며 당연하게 요구할 수 있는 사항이 아니라고 생각합니다.보통 회사에서 프론트 개발자는 어느정도의 권리를 갖는지 궁금합니다.(저의 경우, 저는 회사 소속 백엔드 개발자, 프론트 개발자님은 외주 개발자입니다.)api 구조나 퍼포먼스에 대해 당연하게 요구할 권리가 있나요?

m2m 관계의 api endpoint 설계 in rest api와 의사소통

0개의 답변

Q&A 목록