[작성일: 2023. 09. 28]
회원 등록 API
@RestController
@RequiredArgsConstructor
public class MemberApiController {
private final MemberService memberService;
@PostMapping("/api/v1/members")
public CreateMemberResponse saveMemberV1(@RequestBody @Valid Member member) {
Long id = memberService.join(member);
return new CreateMemberResponse(id);
}
@Data
@AllArgsConstructor
static class CreateMemberResponse {
private Long id;
}
}
회원 등록 V1은 요청 값으로 Member 엔티티를 직접 받는다. (Request Body에 직접 매핑)
이런 경우 몇 가지 문제점이 생기는데,
- 엔티티에 프레젠테이션 계층을 위한 로직이 추가된다.
- 엔티티에 API 검증을 위한 로직이 들어간다. (@NotEmpty 등)
- 실무에서는 회원 엔티티를 위한 API가 다양하게 만들어지는데 한 엔티티에 각각의 API를 위한 모든 요구사항을 담기 어렵다.
- 엔티티가 변경되면 API 스펙이 변한다.
결론은 이렇게 작성하지 말고, API 요청 스펙에 맞춰 별도의 DTO를 파라미터로 받으면 된다.
V2 엔티티 대신에 DTO를 RequestBody에 매핑한다.
@RestController
@RequiredArgsConstructor
public class MemberApiController {
private final MemberService memberService;
// ... 코드 생략
@PostMapping("/api/v2/members")
public CreateMemberResponse saveMemberV2(@RequestBody @Valid CreateMemberRequest request) {
Member member = new Member();
member.setName(request.getName());
Long id = memberService.join(member);
return new CreateMemberResponse(id);
}
@Data
static class CreateMemberRequest {
private String name;
}
}
CreateMemberRequst를 Member 엔티티 대신에 RequestBody와 매핑한다.
- 엔티티와 프레젠테이션 계층을 위한 로직을 분리할 수 있다.
- 엔티티와 API 스펙을 명확하게 분리할 수 있다.
- 엔티티가 변해도 API 스펙이 변하지 않는다.
참고: 실무에서는 엔티티를 API 스펙에 노출해선 안 된다.
회원 수정 API
@RestController
@RequiredArgsConstructor
public class MemberApiController {
private final MemberService memberService;
// ... 코드 생략
@PutMapping("/api/v2/members/{id}")
public UpdateMemberResponse updateMemberV2(@PathVariable("id") Long id,
@RequestBody @Valid UpdateMemberRequest request) {
memberService.update(id, request.getName());
Member findMember = memberService.findOne(id);
return new UpdateMemberResponse(findMember.getId(), findMember.getName());
}
@Data
@AllArgsConstructor
static class UpdateMemberResponse {
private Long id;
private String name;
}
@Data
static class UpdateMemberRequest {
private String name;
}
}
회원 수정도 DTO를 요청 파라미터에 매칭한다.
- 변경 감지를 사용해서 데이터를 수정한다.
참고:
updateMemberV2는 회원 정보를 부분 업데이트 한다.
여기서 PUT 방식을 사용했는데 PUT은 전체 업데이트를 할 때 사용하는 것이 맞다.
부분 업데이트를 하려면 PATCH를 사용하거나 POST를 사용하는 것이 REST 스타일에 맞다.
회원 조회 API
@RestController
@RequiredArgsConstructor
public class MemberApiController {
private final MemberService memberService;
@GetMapping("api/v1/members")
public List<Member> membersV1() {
return memberService.findMembers();
}
// ... 코드 생략
}
임시로 데이터를 넣고 GET으로 데이터 조회를 실행했다.
조회 V1은 응답 값으로 엔티티를 직접 외부에 노출하며 여러 문제점이 발생한다.
- 엔티티에 프레젠테이션 계층을 위한 로직이 추가된다.
- 기본적으로 엔티티의 모든 값이 노출된다.
- 응답 스펙을 맞추기 위해 로직이 추가된다. (@JsonIgnore, 별도의 뷰 로직 등)
- 실무에서는 같은 엔티티에 대해 API가 용도에 따라 다양하게 만들어지는데, 한 엔티티에 각각의 API을 위한 프레젠테이션 응답 로직을 담기는 어렵다.
- 엔티티가 변경되면 API 스펙이 변한다.
- 추가로 컬렉션을 직접 반환하면 향후 API 스펙을 변경하기 어렵다. (별도의 Result 클래스 생성으로 해결)
결론적으로는 API 응답 스펙에 맞춰 별도의 DTO를 반환하는 방법으로 작성해야 한다.
참고: 엔티티를 외부에 노출하지 말자.
실무에서는 member 엔티티의 데이터가 필요한 API가 계속 증가하게 된다.
어떤 API는 name 필드가 필요하지만, 어떤 API는 name 필드가 필요없을 수 있다. 결론적으로 엔티티 대신에 API 스펙에 맞는 별도의 DTO를 노출해야 한다.
회원조회 V2는 응답 값으로 엔티티가 아닌 별도의 DTO를 사용해보자.
@RestController
@RequiredArgsConstructor
public class MemberApiController {
private final MemberService memberService;
@GetMapping("api/v2/members")
public Result membersV2() {
List<Member> findMembers = memberService.findMembers();
List<MemberDto> collect = findMembers.stream()
.map(m -> new MemberDto(m.getName()))
.collect(Collectors.toList());
return new Result(collect);
}
@Data
@AllArgsConstructor
static class Result<T> {
private T data;
}
@Data
@AllArgsConstructor
static class MemberDto {
private String name;
}
// ... 코드 생략
}
- 엔티티를 DTO로 변환해서 반환한다.
- 엔티티가 변해도 API 스펙이 변경되지 않는다.
- 추가로 Result 클래스로 컬렉션을 감싸서 향후 필요한 필드를 추가할 수 있다.
🐣 출처: 인프런 김영한님 강의
이 글은 인프런의 김영한님 JPA 강의를 보고 작성한 글입니다.
강의를 들으면서 정리한 글이므로 틀린 내용이나 오타가 있을 수 있습니다.