결과는 비슷하지만 내용은 다른 유형의 조회 API 통합 vs 분리

Question

안녕하세요.예시로 유저 목록을 들어보겠습니다.유저 관리 페이지에서는 유저 대부분의 정보를 포함하는 리스트를 보여주고 있으며, 검색 조건이 다양하다.사은품 지급 페이지에서는 특정 사은품을 수령한 유저 한정으로 유저의 일부의 정보만 포함하는 리스트를 보여주고 있으며, 검색 조건이 제한되어 있다.2번과 유사한 페이지가 몇개 더 존재하며, 각각 사소한 차이만 존재한다. (특정 상품을 구매한 유저 한정 등)조금 풀어서 설명을 드려보면1번은 심플하게 가입 한 유저 전체 목록을 불러오는 것2번은 특정 사은품을 선택하면 그 사은품을 수령한 유저만 보게끔 필터링이 기본으로 걸리는 것3번은 특정 상품을 선택하면 해당 상품을 구매한 유저만 보게끔 필터링이 기본으로 걸리는 것그러다보니 1번은 단순 user 테이블 조회지만, 2번 3번은 각각 목적에 따라 서로 다른 테이블 join을 추가로 걸어야 합니다.즉 쿼리가 큰 폭에서 달라지게 되는데요.하지만 실제 응답에 필요한 필드는 굉장히 유사하며, 화면 구성 역시 그렇기 때문에겉으로 보기에는 유저 조회하는 API 하나에 조건으로 분기를 태워서 다른 쿼리를 사용하기만 하면 되는게 아닌가..? 라는 상황입니다.그래서 실제로 통합 API로 구현을 했더니, API 구현이 너무 복잡해지지 않았나, 너무 많은 기능을 수행하고 있는 것이 아닌가? 싶습니다.받아야 할 파라미터도 많아지고, 파라미터에 따라 분기까지 태워야 하고, 개발한 당사자가 아니라면 한 눈에 알아보기가 점점 힘들어지더군요.너무 무리하게 클린코드를 지향하고자 오히려 일을 복잡하게 만들고 있는건 아닌가 걱정스럽습니다.그렇다고 API를 모두 분리하자니, 분명 기능은 유저 목록을 보는 기능인데 여기는 이 API, 저기는 저 API, 저어어기는 또다른 API....이것도 과연 이게 맞나...... 싶네요.선생님들께서는 이런 경우 통합 API 1개를 공유하며 사용하게끔 하실까요,아니면 그래도 사용처 및 쿼리까지 다 다르니 개별 API로 분리를 하실까요?

wharup · Accepted Answer

특정 상품, 특정 사은품 1개를 찍고 들어가는 거라면 각기 분리하는게 자연스럽겠네요.단순히 사용자 테이블의 속성이 아니고, 사은품 수령이나 상품 구매를 드라이빙 테이블로 걸고 들어가니까요[GET[ /api/users[GET[ /api/gitfs/{giftId}/users[GET[ /api/products/{productId}/users

장독깨기 · Answer

애매하네요,저 같으면 파라미터로 분기 하느니 API 를 분리하겠습니다. :)

킁킁탐정 · Answer

그 어떤 코드도 개발한 당사자가 아니라면 목적과 의도를 한번에 파악할 수 없습니다.심지어 당사자도 시간이 지나면 목적과 의도를 잊어버리기 쉽습니다.그래서 문서화가 중요하기 도합니다.정보를 사용하는 곳이 다양하고 일부 정보는 숨겨야하는 보안적 위험성이 있거나API 호출로 드는 컴퓨팅 자원이 크고 분할로 감소된다면 분할하는게 좋습니다.아니라면 유지 보수 기준으로 마음에 드는쪽으로 가시면 됩니다.꼭 이렇게 해야 한다라는건 존재하지 않습니다.

Clickin · Answer

보통 클린코드라고 무조건 공통화하는 게 아니라 도메인 단위로 끊어서 생각하는게 많은 경우에서 유지보수가 용이했습니다.라이브러리, 유틸리티 메소드야 최대한 공통화하는 게 맞지만 이 경우는 목적이 달라서 분리하는게 유리하리라 봅니디.

감독님테스트가하고싶어요 · Answer

쪼개야 클린코드에 더 가까워질거같네요.개발한 당사자가 아니라면 한 눈에 알아보기가 점점 힘들어지더군요.이건 클린코드와 정 반대가 아닌가 싶습니다.

결과는 비슷하지만 내용은 다른 유형의 조회 API 통합 vs 분리

5개의 답변

기술 목록