API 응답에 대한 고민
Reserve Me 프로젝트를 진행하며 RESTful한 API 설계에 대해 많이 고민했다.
일관된 응답 포맷을 유지하기 위해 ResponseDTO에 대해서 알아보던 중
CRUD에 따른 ResponseDto를 보내는 유형 및 Respo... - 인프런 | 커뮤니티 질문&답변
누구나 함께하는 인프런 커뮤니티. 모르면 묻고, 해답을 찾아보세요.
www.inflearn.com
인프런의 요니님이 작성한 이 질문글을 보게 되었다.
나도 개발을 하면서 한번쯤 고민해봤던 문제라 아카이빙..
김영한님 답변에서
우리가 API 디자인을 할 때 중요하게 생각해야 하는 부분이 있습니다.
바로 API를 사용하는 클라이언트의 입장을 적극 고려해야 하는 부분입니다.
이 내용이 전체 답변의 내용을 관통한다고 느꼈다.
'API를 사용하는 클라이언트'는 간단하게 프론트엔드라고 이해했다.
그리고 뭐든지 트레이드 오프..
어떤 면에선 장점이, 어떤 면에선 단점이 될 수 있다.
현 상황(팀의 구성, 비지니스 로직)에 따라
적절한 선택을 하는 게 중요한 것 같다.
위 인프런 질문글의 답변과 질문을 요약해봤어요.
자세한 내용은 원글에서 확인해주세요.
Q1
생성 API의 응답 시에
① 엔티티 정보를 DTO로 변환하여 보내는 것이 적절한지,
② 생성된 엔티티의 키(ID)만 반환해야 하는지.
②의 경우 ) 별로도 조회API를 호출해야 하는 것에 대한 비용은?
A1
시스템과 디자인의 트레이드 오프
생성 API 응답에서 ID만 보내고, 나머지 데이터를 다시 조회하는 방식 선호.
=> 데이터 저장과 조회를 깔끔하게 분리
다시 조회하는 것은 시스템의 부하가 UP.
하지만 시스템은 복잡한 조회 때문에 성능이 떨어지는 것.
PK 기준으로 조회하는 것은 미미한 영향.
Q2
수정, 삭제 API에서 엔티티의 ID를 보내지 않고 있음.
김영한님은 어떻게 하고 계신지.
A2
클라이언트의 편리함과 상황 함께 고려
HTTP 상태 코드로 응답을 알 수 있기에 이는 선택.
다만 만약 응답에 ID를 받을 수 있다면,
(예시) 삭제를 요청한 클라이언트가 비동기 콜백으로 요청하게 되면
응답에 ID가 없으면 ID를 어딘가에 관리해야 하는데
응답에 ID를 받을 수 있으면 더 편리하게 코드 작성이 가능.
Q3
질문자: 단건 조회용, 전체 조회용 별도의 ResponseDTO 사용.
팀장님: 프론트가 받는 응답의 일관성을 위해
엔티티별로 모든 필드를 포함한 하나의 ResponseDto.
이를 조합하여 API별 응답DTO 구성.
A3
성능보다 유지보수 관점에서 고민
아래와 같은 트레이드 오프
API에서 모든 데이터를 노출
장) 클라이언트가 필요할 때 자유롭게 사용
단) 서버에서 데이터를 변경할 때 더 많은 고려가 필요
=> 프론트 + 백엔드 한팀의 경우
반대로 일부 데이터만 노출
장) 서버 변경이 용이
단) 클라이언트와의 일관성 문제 발생
=> 다른 팀의 경우