실전! 스프링 부트와 JPA 활용2 - API 개발과 성능 최적화
[1] 회원 등록 API
우선 포스트맨을 다운로드 해야하는데 저는 이미 있으니까 넘어가도록 하겠습니다. 😋
V1 - 비추
: 요청 값으로 Member 엔티티를 직접 받음
에서 POST로 전송하면
문제점
- 엔티티에 프레젠테이션 계층을 위한 로직이 추가된다.
- 엔티티에 API 검증을 위한 로직이 들어간다. (
@NotEmpty...)- 실무에서는 회원 엔티티를 위한 API가 다양하게 만들어지는데, 한 엔티티에 각각의 API를 위한 모든 요청 요구사항을 담기엔 어렵다.
- 엔티티가 변경되면 API 스펙이 변한다.
즉, API 요청 스펙에 맞추어 별도의 DTO를 파라미터로 받는다.
V2
: 엔티티 대신 DTO를 RequestBody에 매핑
CreateMemberRequest를 Member 엔티티 대신 RequestBody와 매핑한다.- 엔티티와 프레젠테이션 계층을 위한 로직을 분리할 수 있다.
- 엔티티와 API 스펙을 명확하게 분리할 수 있다.
- 엔티티가 변해도 API 스펙이 변하지 않는다.
실무에서는 엔티티를 API 스펙에 노출하면 안된다 !!
[2] 회원 수정 API
회원 수정도 DTO를 요청 파라미터에 매핑한다.
그리고 변경 감지를 사용해 데이터를 수정하면 된다.
먼저 등록해준 뒤 이름을 수정해주면
잘 수정된 결과를 확인할 수 있다.
[3] 회원 조회 API
application.yml에ddl-auto: none으로 (원랜 create) 잠깐 바꾸어 데이터가 날아가지 않도록 하자.그러고 회원을 이렇게 미리 만들어놓기
V1
: 응답 값으로 엔티티를 직접 외부에 노출
그런데!! 주문 정보까지 함께 나와버림.
이럴 때는 member.java에서 @JsonIgnore 어노테이션을 추가해주면 된다.
문제점
- 엔티티에 프레젠테이션 계층을 위한 로직이 추가된다.
- 기본적으로 엔티티의 모든 값이 노출된다. → 극단적으로 패스워드와 같은 정보가 있다고 할 때 그대~로 모~두 노출된다는 것
- 응답 스펙을 맞추기 위해 로직이 추가된다. (
@JsonIgnore, 별도의 뷰 로직 ...)- 실무에서는 같은 엔티티에 대해 API가 용도에 따라 다양하게 만들어지는데, 한 엔티티에 각각의 API를 위한 프레젠테이션 응답 로직을 담기엔 어렵다.
- 엔티티가 변경되면 API 스펙이 변한다. (name → username으로 바꿔버리면 큰일)
- 추가로 컬렉션을 직접 반환하면 향후 API 스펙을 변경하기 어렵다. (별도의 Result 클래스 생성으로 해결)
그런데 실무에서는 절대 엔티티를 직접 반환시키면 안된다.
실무에서는 member 엔티티의 데이터가 필요한 API가 계속 증가하게 된다. 어떤 API는 name 필드가 필요하지만 어떤 API는 name 필드가 필요없을 수도 있다.
결론적으로 엔티티 대신 API 스펙에 맞는 별도의 DTO를 노출해야 한다.
즉, API응답 스펙에 맞춰 별도의 DTO를 반환하자
V2
: 응답 값으로 엔티티가 아닌 별도의 DTO 사용
- 엔티티를 DTO로 변환해 반환
- 엔티티가 변해도 API 스펙이 변경되지 않음
- 추가로 Result 클래스로 컬렉션을 감싸 향후 필요한 필드를 추가할 수도 있음
개발 바보 이사 중