관계형 디비 api설계와 프론트엔드에서 처리

Question

관계형 데이터베이스를 사용중인데

총 10개의 칼럼이있는 테이블1과 총 13개의 칼럼이있는 테이블2 를 조인해서 응답해주는 API가 있는데요,

화면에서 필요한 칼럼은 테이블1에서 3개, 테이블2에서 5개 입니다.

이럴 때 테이블2개를 조인해서 카8개를 가진 json으로 리턴해주고 있는데요,

프론트엔드에서 테이블1에 해당하는 타입과, 테이블2에 해당하는 타입을 이미 지정해 놓아서 해당 방식으로 리턴해주면 조인을 하는 API마다 새로운 타입을 정의해야되서 조금 불편한것같다

라는 의견이 있었습니다.

보통 관계형 데이터베이스를 사용해서 조인 후 리턴하는 경우 api는 어떻게 설계하는게 좋을까요?

ㄱㅎㅁ · Answer

프론트 개발자 분 입장에서는 미리만들어둔 타입의 형태로 내려주면 작업을 덜해도 좋겠지만, 
백엔드 API 입장에서는 특정 API는 보여줄것과 안보여줄것을 명확히 구분해야할 의무가 있습니다. 보안측면에서 api단에서 보여줄데이터를 정해서 주면 좋으니까요.
백엔드에서 response Dto는 API마다 분리하는것이 추후 기능 추가요건이 들어오면 수정이 간편해집니다.

뭣하면 다음과 같은 방식은 return을 하면 가능할거 같네요.

{
    테이블1: {테이블1의 3개만 담겨있는 object},
    테이블2: {테이블2의 5개만 담겨있는 object}
}

이렇게 해두면 front 입장에서는 테이블1 key를 가지고 있는 object를 테이블1타입,
테이블2 key를 가지고 있는 object를 테이블2타입 으로 캐스팅해서 사용할순 있지 않을까 싶네요.

그렇지만 front에서도 명확히 타입을 분리해서 쓰라고 하고싶은게, 추후에 테이블1타입으로 받아온 객체중에 없는 데이터를 테이블1타입에 있으니 사용하는 휴먼에러가 있을것 같습니다.