[Spring] JPA 활용2 - API 개발 기본

안녕하세요 안녕주입니다. 

오늘은 인프런의 JPA 활용2 강의를 들으면서 복습 겸 정리한 블로그를 올리려고 합니다.

 

회원 등록 API

package jpabook.jpashop.api;

import jpabook.jpashop.domain.Member;
import jpabook.jpashop.service.MemberService;
import lombok.Data;
import lombok.RequiredArgsConstructor;
import org.springframework.web.bind.annotation.PostMapping;
import org.springframework.web.bind.annotation.RequestBody;
import org.springframework.web.bind.annotation.RestController;

import javax.validation.Valid;

@RestController
@RequiredArgsConstructor
public class MemberApiController {
    private final MemberService memberService;
    /**
     * 등록 V1: 요청 값으로 Member 엔티티를 직접 받는다.
     * 문제점
     * - 엔티티에 프레젠테이션 계층을 위한 로직이 추가된다.
     * - 엔티티에 API 검증을 위한 로직이 들어간다. (@NotEmpty 등등)
     * - 실무에서는 회원 엔티티를 위한 API가 다양하게 만들어지는데, 한 엔티티에 각각의 API를
     위한 모든 요청 요구사항을 담기는 어렵다.
     * - 엔티티가 변경되면 API 스펙이 변한다.
     * 결론
     * - API 요청 스펙에 맞추어 별도의 DTO를 파라미터로 받는다. */
    @PostMapping("/api/v1/members")
    public CreateMemberResponse saveMemberV1(@RequestBody @Valid Member member)
    {
        Long id = memberService.join(member);
        return new CreateMemberResponse(id);
    }
    @Data
    static class CreateMemberRequest {
        private String name;
    }
    @Data
    static class CreateMemberResponse {
        private Long id;
        public CreateMemberResponse(Long id) {
            this.id = id;
        } 
    }
}

V1 엔티티를 Request Body에 직접 매핑하는 방법

• 문제점
  • 엔티티에 프레젠테이션 계층을 위한 로직이 추가된다.
  • 엔티티에 API 검증을 위한 로직이 들어간다 ( 엔티티에 @NotEmpty를 추가해야하는 문제가 생김 → 만약 어떤 API에서는 NotEmpty일 필요가 없을 경우 복잡해지는 문제가 또 발생)
  • 위의 내용을 부연 설명하면 회원 엔티티를 위한 다양한 API 의 모든 요청 요구사항을 담기 어렵다.
  • 엔티티가 변경되면 API 스펙이 변한다(name → username으로 바꿀시 api 동작 안함)
• 결론
  • API 요청 스펙에 맞추어 별도의 DTO를 파라미터로 받는다

 

 

V2 엔티티 대신에 DTO를 RequestBody에 매핑

		/**
     * 등록 V2: 요청 값으로 Member 엔티티 대신에 별도의 DTO를 받는다.
     */
    @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);
    }

• CreateMemberRequest를 Member 엔티티 대신에 RequestBody와 매핑한다.
• 엔티티와 프레젠테이션 계층을 위한 로직을 분리할 수 있다.
• 엔티티와 API 스펙을 명확하게 분리할 수 있다.
• 엔티티가 변해도 API 스펙이 변하지 않는다.
• V1의 문제점-2번을 해결할 수 있음

참고 : 엔티티를 API 스펙에 노출하면 안된다!!!

 

 

---

 

회원 수정 API

/**
     * 수정 API
     */
    @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를 요청 파라미터에 매핑

 

public class MemberService {

	private final MemberRepository memberRepository;

/**
      *  회원 수정 */
    @Transactional
    public void update(Long id, String name) {
        Member member = memberRepository.findOne(id);
        member.setName(name);
    }
}

• 변경 감지를 사용해서 데이터를 수정

위의 updateMember2는 회원정보를 부분 업데이트한다. 여기서 PUT은 전체 엄데이트를 할때 사용하는 것이라, 부분업데이트는 PATCH나 POST를 사용하는 것이 REST 스타일에 맞다.

 

---

회원 조회 API

회원조회 V1: 응답 값으로 엔티티를 직접 외부에 노출

//조회 V1: 안 좋은 버전, 모든 엔티티가 노출, @JsonIgnore -> 이건 정말 최악, api가 이거 하나인가! 화면에 종속적이지 마라!
    @GetMapping("/api/v1/members")
    public List<Member> membersV1() {
        return memberService.findMembers();
    }

1. yml 파일에 ddl-auto에 none설정
2. jpa application실행
3. localhost:8080 사이트에서 member1, member2 생성해서 Data 쌓기
4. 그리고 api 조회하기

 

조회 V1 의 문제점

• 엔티티에 프레젠테이션 계층을 위한 로직이 추가된다.
• 기본적으로 엔티티의 모든 값이 노출된다. (order entity는 필요없는데 전부 노출된다)
• 응답 스펙을 맞추기 위해 로직이 추가된다. (@JsonIgnore, 별도의 뷰 로직들이 추가된다.)
• 같은 엔티티에 대해 다양한 API가 용도에 따라 다양하게 만들어 지는데, JsonIgnore 같은 것을 사용하게 되면, 한 엔티티에 각각의 API를 위한 프레젠테이션 응답 로직을 담기는 어렵다.
• 엔티티가 변경되면 API 스펙이 변한다.
• 추가로 컬렉션을 직접 반환하면 향후 API 스펙을 변경하기 어렵다. ( 별도의 Result 클래스 생성으로 해결)

결론

• API 응답 스펙에 맞추어 별도의 DTO를 반환한다.

엔티티를 외부에 노출하지 마세요! 결론적으로 엔티티 대신에 API 스펙에 맞는 별도의 DTO를 노출해야 한다.

 

 

회원조회 V2: 응답 값으로 엔티티가 아닌 별도의 DTO 사용

/**
     *조회 V2: 응답 값으로 엔티티가 아닌 별도의 DTO를 반환한다.
    */
    @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;
    }

• 엔티티를 DTO로 변환해서 반환한다.
• 엔티티가 변해도 API 스펙이 변경되지 않는다.
• 추가로 Result 클래스로 컬렉션을 감싸서 향후에 필요한 필드를 추가할 수 있다.( 기존에는 배열에 안에 데이터들만 있었는데, 껍데기인 {}로 감싸고 그 안에 count같은 값을 넣고 그 아래에 Data : [] 배열을 넣음으로써 활용이 쉬움)

 

---

개인적으로 궁금한것

1. @RestController
2. @RequestBody
3. Valid
4. .join
5. @Data
6. @AllArgsConstructor
7. @PutMapping
8. @PathVariable
9. .update
10. .findOne
11. @Transactional
12. .map
13. .collect
14. .stream