RESTFUL API의 관점에서 API 설계중 질문이 있습니다.

Question

안녕하세요. 2년차 백앤드 개발자입니다. 현재 회사에서 프로젝트를 리팩토링하는 과정중입니다.저희 서비스에서 DDD + Hexagonal Architecture + Spring Monolith 기반으로 서비스를 설계하고 있습니다.도메인은 모두 독립된 bounded context와 각각의 aggregate로 분리해 운영하고 있습니다.문제는 GET API를 어떻게 설계할지가 모호해지고 있다는 점입니다.제가 지금까지 가지고 있던 철학(?)아닌 관습은 RESTFUL 한 API는 엔드포인트가 리소스 관점이어야하며, 여기서 말하는 리소스란 서버 도메인상 즉, 어그리거트던 vo가 됐건 서버의 리소스라는 점이었습니다.그러나 아키택처를 리팩토링 하는 과정속에서 GET API, 즉 조회의 경우, 이걸 RESTFUl의 원칙중 리소스의 관점을 서버에 향해야하는가? 에 대한 의문이 생겼습니다. 예를 들어 유저가 속한 BC가 A, 또 다른 BC가 B, C, D라고 할때, 유저가 로그인을 하고 처음진입하는 화면, HOME에서 A,B,C,D의 모든 정보가 필요 하다고 가정했을때,기존에는 A,B,C,D에서 각각의 API를 조회해 프론트에서 조합을 진행했습니다. 그러나 여기서 생기는 문제는 네트워크 트래픽, 그리고 DB의 IO, 뿐만 아니라 유저의 UX를 해친다는 결론이 나왔습니다. 이는 최소 4개의 API의 호출이 필요하고, 프론트에서 비즈니스 규칙이 노출될 위험이 있다고 생각했습니다.이 문제를 HOME에서 만약 하나의 API, 예를 들어 /v1/users/home을 요청한다면 해결할수 있다고 생각했습니다. 제가 드리고 싶은 질문은 리소스라는 관점을 서버에 한에서 두는게 아닌 클라이언트에서 필요한 데이터에 초점을 맞춰 엔드포인트에 그 목적성을 드러내도 되는가 입니다.(저희는 graphql등은 사용하지 않습니다.)만약 그렇게 하는경우 지켜야하는 원칙이 있을까요? 혹은 현업에서 지키는 원칙이 있을까요?DDD 관점 + 실무 관점에서GET API를 어떻게 설계하는 것이 가장 적절하고 유지보수성이 좋은지 베스트 프랙티스를 알고 싶습니다.

2948284 · Answer

그런 구조에 그런 요청이라면‘프론트엔드를 위한 백엔드‘ 서버가여러도메인의 요청을 병합해서 내려주는게 가장 베스트같습니다

집킨 · Answer

BFF 패턴 검색해보세요

라벨리 · Answer

기술적으로 도메인 레벨로 완전히 분리된 api가 바람직하겠지만 , 대부분의 경우 그렇게 도메인단위로 잘린 api 뭉치를 사용할수는 없을겁니다. 다른분들이 추천해주신 BFF 도, api서버가 아닐 뿐이지 화면맞춤형 데이터를 내리는 api를 만드는 방향입니다.제 관점에서 api는 외부 누군가의 유즈케이스 대응을 위한 외부 통신 기능인데, api 가 가리키는 리소스가 반드시 도메인과 일치할 필요는 없을것 같습니다. 가령 도메인을 조합하더라도(A+B+C) 특정 유즈케이스상의 의미있는 리소스로 개념지을 수 있다면 여전히 restful 하다 봅니다. 그게 도메인과는 다르더라도요. 어차피 application 레이어에서 도메인이 섞이는건 의도된 설계이고 그렇게 쓰셔도 됩니다. 예시를 들어보면 home 경로에서 필요한 데이터가 "장바구니목록(A)과 그 아이템의 최근구매일자(B)" 라고 하면, A와 B을 묶어 CartHistory 와 같은 리소스 개념을 정의하여 호출하면 됩니다. 조회 함수는 A+B를 효과적으로 조회할 수 있도록 최적화 해주고요. 함께 잘 쓰이면서 조회 최적화가 필요한 데이터를 묶어보려 이리저리 재보았던것 같습니다.api가 자유롭게 나오기 시작하면 리소스를 조회하는 여러가지 방법이 생길수도 있습니다. 괜찮습니다. Read는 다양하게 나올수밖에 없습니다. presentation 이 복잡해진 것이지, 도메인이 오염된것은 아닙니다.(다만 CUD 작업을 하는 endpoint는 aggregate에 맞게 하나만 쓰시기 바랍니다)비슷한것들 적당히 뭉쳐서 딱 필요한것보다 약간 더 넓게 커버하는 정도로 만들면 또 api몇개가 합쳐집니다. 보통은 크게 문제가 없다면 이정도 선에서 비효율을 감수하고 api를 몇번정도 호출하는 선에서 마무리 합니다. 조회 최적화도 간단한 캐시 정도로 해결되는 경우가 많습니다. 호출이 몇번씩 되고 렌더링 단계가 생기지만 이정도는 현재의 복잡함을 받아들이고 씁니다. 어떤 시나리오에서는 client가 너무 많아서 조금씩 다른 리소스 개념들 관리가 안 될 때가 있습니다. 그러면 api서버의 조회용 로직을 다 모아모아 BFF서버를 고려합니다. 근데 조금씩 다른 조회 api가 최소 50개쯤은 되어야 분리합니다. 그 이하는 배보다 배꼽이 더 큽니다.어떤 시나리오에서는 데이터 조회비용이 너무나 커서 최적화를 극단적으로 해야한다거나, 무조건 한번의 api콜로 그 페이지에서 필요한 데이터를 줘야할 수 있습니다. 그럴 경우에는 그냥 /home 을 만들고 맞춤형 api 를 1:1 로 만들어준 다음 격리시킵니다. restful 과 상관없어집니다. 그 endpoint는 페이지 완전 맞춤형으로 정의하고 버리는거죠. "restful api 를 만들줄 알지만 이번에 FE요청이 그렇게 와서 최적화를 한 것이다" 생각하면 그리 문제될건 없습니다. 현업에서 종종 있는 일이고 둘 다 경험해 보는것도 나쁘지 않았습니다격리하는 방법은 api path 레벨에서 분기 + 어플리케이션 패키지 구분할때도 있고 다른분들 제안처럼 BFF를 만들 경우도 있습니다. 하지만 격리만을 위해 BFF를 쓰는건 관리 부담이 더 클 수 있으니 주의하세요.

RESTFUL API의 관점에서 API 설계중 질문이 있습니다.

3개의 답변

Q&A 목록