인프런 커뮤니티 질문&답변
작성한 질문수
api 응답객체 네이밍 및 new에 대해
해결된 질문
작성
·
631
0
안녕하세요. 강의 너무 잘 보고 있습니다.
좋은 컨텐츠를 제공해주시는 인프런과 영한님, 서포터분들께 감사드립니다.
api응답 객체 네이밍에 대해 질문이 있습니다.
등록,수정의 경우 응답객체 네이밍이 ~~Response
조회의 경우 MemberDTO 를 Result로 래핑해서 보내는데
DTO와 Response로 네이밍하는 기준이 있는지 궁금합니다.
또 하나는, 좀 엉뚱한 질문일 수도 있는데
응답시마다 new를 통해 응답객체를 생성하는데
대규모 시스템에 성능에 크게 문제가 없는지와
응답 객체를 싱글톤으로 만드는 패턴같은것도 있는지 궁금합니다.
감사합니다.
퀴즈
API 개발에서 JPA 엔티티 객체를 요청 파라미터나 응답 값으로 직접 사용하는 것을 지양해야 하는 주된 이유는 무엇일까요?
데이터베이스 성능이 저하되기 때문입니다.
API의 스펙이 엔티티의 변화에 직접적으로 영향을 받기 때문입니다.
클라이언트 측의 데이터 파싱 로직이 복잡해지기 때문입니다.
네트워크 전송량이 불필요하게 증가하기 때문입니다.
답변 1
3
안녕하세요. cw k님
프로젝트 마다 다를 것 같기는 한데요. 저는 특별한 네이밍 규칙을 가지고 있지는 않습니다.
API 응답의 최종 껍데기는 Response를 포함한다 정도가 규칙이 될 수는 있는데, 이런 규칙은 구성원들과 프로젝트를 진행하면서 합의를 이루는 것이 필요할 수 는 있습니다.
DTO는 데이터 전송 객체라는 뜻인데, 가장 광범위하게 데이터를 전달하는 목적으로 사용되는 객체를 뜻합니다.
DTO는 객체간의 전송에도 사용되고, API 응답에도 사용되는 가장 광범위한 의미로 생각하시면 됩니다.
Q: 응답시마다 new를 통해 응답객체를 생성하는데 대규모 시스템에 성능에 크게 문제가 없는지
-> 네 자바의 GC 성능은 매우 뛰어나기 때문에 이런 부분으로 성능 문제가 발생하지는 않습니다. 응답 객체를 싱글톤으로 구현하게 되면 멀티쓰레드 상황에서 공유 이슈가 발생하기 때문에 더 큰 문제가 발생할 수 있습니다. 그리고 더 나아가서 응답 객체들을 풀에 넣어두고 재사용하는 객체 풀링도 방법이 될 수 있지만, 이 경우에도 멀티쓰레드 상황에서 동시에 여러 쓰레드가 객체 풀에 접근하는 동시성 이슈를 락 등으로 해결해야 합니다. 현대에는 GC 성능이 매우 뛰어나기 때문에, 객체를 new로 생성해서 GC 하는 비용은 매우 저렴합니다. 결과적으로 멀티쓰레드 상황에서는 객체 풀링을 사용하는 비용보다 new를 직접 사용하는 것이 더 좋은 성능을 보입니다.
감사합니다.
답변 감사드립니다!