[개발생각] API 패키지를 어떻게 관리하면 될까?

클린코드에서든 레거시에서든, 어떻게 해야할까?라는 생각이 잠깐씩 들때가 있다. 바로 API패키지를 어떻게 가져가야하지? 생각이다.

 

 

UserGetUsecase, OrderGetUsecase, ProfileGetUsecase가 있다고 하자!

앱내의 My탭에서 정보조회를 해야하는데, 여러 이유때문에 User, Order, Profile정보를 하나의 API로 제공을 해야한다.

또는 앱에서의 여러번의 API호출을 줄이기위해, API를 묶어서 한번에 조회하는 API를 제공해야한다면..

이런경우, Facade를 만들거나, 컴포지트 Service를 만들어서 여러개를 조회해서, DTO로 내려주면 되기에, 큰 고민은 없는뎅...

 

고민은 DTO와 Package명, api경로가 영 너무 맘에 안들게 된다.

예를 들면)

 

/api/v1/user/login

/api/v1/user/logout

 

/api/v1/order/register

/api/v1/order/get/all

 

/api/v1/profile/register

/api/v1/profile/get/all

 

등으로 usecase단위로 api를 만드는데, 갑자기 위와 같은 상황이 되면,  API의 경로를 어떻게 해야할지가 순간적으로 고민이된다.

 

/api/v1/my_tab/get ===> ???

/api/v1/user_order_profile/get ===> ???

/api/v1/my_tab/info/get ===> ???

 

뭔가 다 어색해...

 

user, order, profile와 my_tab가 depth도 안맞고, 의미도 안맞고...쩝

 

비즈니스 로직을 나타내는 개념이면 가장 좋을턴데...

my_tab에서 조회해야하는 API를 어떤이름으로 api uri를 따야하는걸까??

bff서버가 있으면, 아예 깔끔하게 분리가 되니, 좋을테지만,

 

그래서 생각한건..

비즈니스로직용 API와 앱에서 사용할 view용 api의 경로를 명시적으로 분리해서 관리하는게 낫겠다고 결정했다.

 

비즈니스로직용 API 

 

/api/v1/user/login

/api/v1/user/logout

 

/api/v1/order/register

/api/v1/order/get/all

 

/api/v1/profile/register

/api/v1/profile/get/all

 

 

view용 API (앱에서 메뉴별 API, 성능상의 이유로 여러 비즈니스 usecase의 데이터를 한번에 내려줘야하는 API)

 

/api/v1/view/my_tab/get

/api/v1/view/my_tab/profile/register

 

이런식으로 /view/ 나 차라리 /app/ 의 path를 명시적으로 추가하고, 분리해서 관리하고,

DTO도 비즈니스로직용과 view용 DTO를 아예 분리해서 관리하면, 혼란이 없을듯하다.

 

위의 문제들은 여태 고민을 한적이 없었는데, 이상하게 이번 프로젝트는 고민포인트로 다가왔다..

뭔가, 성능을 좋게해야하고, API의 호출을 줄여야하고, 효율적으로 동작해야한다는 생각때문인것 같기도 하고...

 

뭐, 정답은 없기에, 관리의 편리성과 통일성등에 좀더 초점을 맞추어 진행하면 될것같다!!

프로그래밍에는 정답이 없다!

 

다음주에는, 위 결정한것에 맞춰서, 정리안된 API들을 늦기전에 정리를 해야지 ㅠㅠ...

여유가 없다.