한 번의 API 콜로 가져오기 vs API 콜을 여러 번 하기

API 를 만들 때, 화면에 필요한 정보를 하나의 API 응답에 담아서 보내줄 수도, API 를 분리하여 클라이언트에서 여러 번 호출하게 할 수도 있다.

다른 말로 하자면 API 를 화면 중심으로 설계하느냐 vs RESTful 하게 설계하느냐라고도 말할 수 있을 것 같다.

 

나는 상황에 따라 다르겠지만 아래와 같은 이유로 대부분의 경우 API 를 분리하는 것을 선호한다.

• API 가 최대한 작은 책임을 갖게되어 유지보수와 재사용성에 유리하다.
• 어떤 역할을 하는 API 인지 명확하게 알 수 있다. 화면 중심으로 설계하게 되면 여러 정보들이 함께 반환하니 URL 을 어떻게 지을지 고민이 생기는데 분리한다면 그런 점이 없다.
• 어떤 API 인지 명확하기에 협업에도 유리하다. 타인이 봤을 때도 명확하게 알 수 있기 때문이다.
• 성능 상의 큰 차이가 없다. 화면 중심으로 설계를 했을 시보다 API 호출이 많아지지만, API 를 비동기적으로 호출하여 화면에 그리기에 성능 상의 큰 차이가 없다. 오히려, 한번에 불러오는 것이 데이터가 많아진다면 더 느릴 수도 있다.
• 추후에 모종의 이유로 API 를 합쳐야하는 일이 생긴다고 하더라고, 쪼개져 있는 것을 합치는 것이 합쳐진 것을 쪼개는 것보다 쉽다.

 

대안

• 전자의 경우로 화면 중심으로 API 를 설계를 한다하더라도 Facade 레이어를 두면 재사용성을 어느정도 챙길 수 있다. 서비스 단의 메서드들은 최대한 하나의 책임만 가지도록 분리를 하고 Facade 레이어에서 조립을 하는 방식이다. API 자체는 여전히 화면에 종속적이지만, 서비스 메서드들의 재사용성을 살려서 다른 API 를 만들 때 용이하게 하는 것이다.
• API 를 분리하면서 재사용성을 챙기기에 클라이언트에서 필요하지 않은 정보까지 받아오는 Over-fetching 문제가 생길 수 있다. 또, API 를 분리하기 때문에 화면에 필요한 데이터를 다 받아오지 못하고 여러 번 요청을 해야 하는 Under-fetching 문제도 있다. 이런 문제들이 싫다면, GraphQL 을 이용해 한 번의 API 요청으로 필요한 데이터만 받아오게 할 수 있다.