- 회원 등록 API
@RestController
//Controller + ResponseBody를 합친 것으로 Body에 json을 통해 데이터를 전달한다.
@RequiredArgsConstructor
public class MemberApiController {
private final MemberService memberService;
//기존에 작성되어 있는 Service
@PostMapping("/api/v1/members")
public CreateMemberResponse saveMemberV1(@RequestBody @Valid Member member)
{
Long id = memberService.join(member);
return new CreateMemberResponse(id);
//CreateMemberResponse를 반환함으로서 @Data를 통해 해당 값들을
//body에 json 형태로 담아서 반환한다.
}
@Data
static class CreateMemberResponse {
private Long id;
public CreateMemberResponse(Long id) {
this.id = id;
}
}
}
- 위 코드의 문제점
1. 엔티티(Member)에 프레젠테이션 계층을 위한 로직이 추가된다.
2. 엔티티에 API 검증이 필요하면 로직이 들어갈 수 있다.
3. 엔티티가 변경되면 API 스펙이 변경된다.
* API 요청 스펙에 맞춰 별도의 DTO를 파라미터로 받아야 한다!!!!!!!
@RestController
//Controller + ResponseBody를 합친 것으로 Body에 json을 통해 데이터를 전달한다.
@RequiredArgsConstructor
public class MemberApiController {
private final MemberService memberService;
//기존에 작성되어 있는 Service
@PostMapping("/api/v2/members")
public CreateMemberResponse saveMemberV2(@RequestBody @Valid CreateMemberRequest request) {
//@RequestBody는 json으로 넘어온 데이터를 파라미터에 바인딩한다.
Member member = new Member();
//새로운 Member객체를 생성한다.
member.setName(request.getName());
//DTO를 통해 Member 객체의 값을 변경한다.
Long id = memberService.join(member);
return new CreateMemberResponse(id);
//DTO를 통해 변경한 Member의 객체를 Response로 넘긴다.
}
@Data
static class CreateMemberRequest {
private String name;
}
@Data
static class CreateMemberResponse {
private Long id;
public CreateMemberResponse(Long id) {
this.id = id;
}
}
}
1. 엔티티와 프레젠테이션 계층을 위한 로직을 분리할 수 있다.
2. 엔티티와 API 스펙을 명확하게 분리할 수 있다.
3. 엔티티가 변해도 API 스펙이 변하지 않는다.
- CreateMemberRequest(DTO)가 API 스펙이 되기 때문에 클라이언트는 DTO만 확인해서 json에 데이터를 넣어 전송하면 된다.
- 엔티티를 파라미터로 넘길 경우 엔티티 정보를 전부 노출하게 되고, 엔티티의 필드값은 API 스펙만을 위한 값이 아니기 때문에 다른 이유로 변경되면 API 스펙이 변경되기 떄문에 큰 혼란이 올 수 있다.
- DTO의 경우 API 스펙을 위해 생성되었기 떄문에 클라이언트는 DTO만 확인하면 되는 편리함이 있다.
- 회원 수정 API
@RestController // 위의 두개가 합쳐진 것 body를 통해 데이터를 전달 (json, xml)
@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
static class UpdateMemberRequest {
private String name;
}
@Data
@AllArgsConstructor
static class UpdateMemberResponse {
private Long id;
private String name;
}
- 회원 수정의 경우에도 별도의 DTO를 생성하여 MemberService(기존에 작성되어 있는 상태 update하기 위한 로직이 작성되어있다.)의 update 메서드를 사용하여 변경한다.
- update를 위한 별도의 DTO를 작성해주는 것이 좋다. 등록과 수정은 차이가 있기 떄문이다.
- PUT의 경우 전체 업데이트를 사용할 때 사용한다. PUT 대신 POST를 사용하는 것이 REST 스타일에 더 어울린다.
- 회원 조회 API
package jpabook.jpashop.api;
@RestController
@RequiredArgsConstructor
public class MemberApiController {
private final MemberService memberService;
@GetMapping("/api/v2/members")
public Result membersV2() {
List<Member> findMembers = memberService.findMembers();
//엔티티 -> DTO 변환
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;
}
- Member를 직접 외부에 노출하는 것은 위험하고, 다른 이유로 API 스펙이 바뀔 수 있기 때문에 별도의 DTO를 생성하여 반환한다.
- 엔티티가 변해도 API 스펙이 변경되지 않는다.
- 추가로 Result 클래스로 컬렉션을 감싸서 향후 필요한 필드를 추가할 수 있다.
출처 : 인프런 - 김영한 (실전! 스프링 부트와 JPA 활용2 - API 개발과 성능 최적화)
'Programming > JPA' 카테고리의 다른 글
JPA - API (지연 로딩과 조회 성능 최적화) 컬렉션 조회 최적화 (0) | 2023.07.22 |
---|---|
JPA - API (지연 로딩과 조회 성능 최적화) 기본 (0) | 2023.07.21 |
JPA - 벌크 연산 (0) | 2023.07.19 |
JPA - 엔티티 직접 사용 (0) | 2023.07.19 |
JPA - 페치 조인 (2) (0) | 2023.07.19 |