[JPA] API 개발 기본

728x90

회원 등록 API

1. V1 - 요청 값을 엔티티로 받기

📌 MemberApiController - 컨트롤러

package bookbook.shopshop.api;

import bookbook.shopshop.domain.Member;
import bookbook.shopshop.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 검증을 위한 로직이 들어간다. (@NotEmpyt 등등)
     *    - 실무에서는 회원 엔티티를 위한 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 CreateMemberResponse {
        private Long id;

        public CreateMemberResponse(Long id) {
            this.id = id;
        }
    }

}

api/MemberApiController
요청 값을 엔티티로 받았다.
엔티티 변경시 api 스펙도 바뀌는 문제가 발생한다.

2. V2 - 요청 값을 DTO로 받기

📌 MemberApiController - 컨트롤러

package bookbook.shopshop.api;

import bookbook.shopshop.domain.Member;
import bookbook.shopshop.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;

    /**
     * 등록 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);
    }

    @Data
    static class CreateMemberRequest {
        @NotEmpty
        private String name;
    }

    @Data
    static class CreateMemberResponse {
        private Long id;

        public CreateMemberResponse(Long id) {
            this.id = id;
        }
    }

}

CreateMemberRequest 객체를 Member 엔티티 대신에 RequestBody와 매핑한다.

🔍 DTO 사용시 장점

DTO를 사용함으로써 엔티티와 프레젠테이션 계층을 위한 로직을 분리할 수 있다.
DOT와 엔티티를 명확히 분리하여 엔티티를 변경해도 api 스펙이 변하지 않는다.
api 스펙에 맞는 양식으로 별도의 DTO를 만들면 유지보수하기 용이하다.

🧷 참고

실무에서는 엔티티를 API 스펙에 노출해서는 안된다.
엔티티를 요청 값이여도 안되고 반환해서도 안된다.

회원 수정 API

1. 회원 수정 - PutMapping

🔍 ItemService

📌 ItemService

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

ItemService 전체 코드

package bookbook.shopshop.service;

import bookbook.shopshop.domain.Member;
import bookbook.shopshop.repository.MemberRepository;
import lombok.RequiredArgsConstructor;
import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Transactional;

import java.util.List;

@Service
@Transactional(readOnly = true)
@RequiredArgsConstructor
public class MemberService {

    private final MemberRepository memberRepository;

    /**
     * 회원 가입
     */
    @Transactional
    public Long join(Member member) {
        validateDuplicateMember(member);
        memberRepository.save(member);
        return member.getId();
    }

    /**
     * 중복 검사
     */
    private void validateDuplicateMember(Member member) {
        List<Member> findMembers = memberRepository.findByName(member.getName());

        if (!findMembers.isEmpty()) {
            throw new IllegalStateException("이미 존재하는 회원입니다.");
        }
    }

    /**
     * 회원 전체 조회
     */
    public List<Member> findMembers() {
        return memberRepository.findAll();
    }

    /**
     * 회원 단 건 조회
     */
    public Member findOne(Long memberId) {
        return memberRepository.findOne(memberId);
    }

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

🔍 MemberApiController

📌 MemberApiController

/**
 * 수정 API
 */
@PutMapping("/api/v2/members/{id}")
public UpdateMemberResponse updateMemberV2(
        @PathVariable 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;
}

📌 MemberApiController 전체 코드

package bookbook.shopshop.api;

import bookbook.shopshop.domain.Member;
import bookbook.shopshop.service.MemberService;
import lombok.AllArgsConstructor;
import lombok.Data;
import lombok.RequiredArgsConstructor;
import org.springframework.web.bind.annotation.*;

import javax.validation.Valid;

@RestController
@RequiredArgsConstructor
public class MemberApiController {

    private final MemberService memberService;

    /**
     * 등록 V1 : 요청 값으로 Member 엔티티를 직접 받는다.
     * 문제점
     *  - 엔티티에 프레젠테이션 계층을 위한 로직이 추가된다.
     *    - 엔티티에 API 검증을 위한 로직이 들어간다. (@NotEmpyt 등등)
     *    - 실무에서는 회원 엔티티를 위한 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);
    }

    /**
     * 등록 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);

    }

    /**
     * 수정 API
     */
    @PutMapping("/api/v2/members/{id}")
    public UpdateMemberResponse updateMemberV2(
            @PathVariable 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;
    }


    @Data
    static class CreateMemberRequest {
        private String name;
    }

    @Data
    static class CreateMemberResponse {
        private Long id;

        public CreateMemberResponse(Long id) {
            this.id = id;
        }
    }


}

PUT은 전체 업데이트를 할 때 사용한다.
부분 업데이트를 하려면 PATCH 메서드를 사용하거나 POST를 사용해야한다.

회원 조회 API

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

📌 MemberController

// 조회 V1 : 안좋은 버전, 모든 엔티티가 노출된다.
@GetMapping("/api/v1/members")
public List<Member> membersV1() {
    return memberService.findMembers();
}

문제점
- 엔티티에 프레젠테이션 계층을 위한 로직이 추가된다.
- 기본적으로 엔티티의 모든 값이 노출된다.
- 응답 스펙을 맞추기 위해 로직이 추가된다. (@JsonIgnore, 별도의 뷰 로직 등등)
- 실무에서는 같은 엔티티에 대해 API가 용도에 따라 다양하게 만들어지는데, 한 엔티티에 각각의 API를 위한 프레젠테이션 응답 로직을 담기가 어렵다.
- 엔티티가 변경되면 API 스펙이 변한다.
- 컬렉션을 직접 반환하면 향후 API 스펙을 변경하기 어렵다.
  - 별도의 Result 클래스 생성으로 해결할 수 있다.
결론
- API 응답 스펙에 맞춰 별도의 DTO를 반환해야 한다.

🧷 참고

엔티티를 절대 외부로 노출하면 안된다.
API 스펙에 맞는 별도의 DTO를 노출해야 한다.

📌 Member 엔티티

package bookbook.shopshop.domain;

import com.fasterxml.jackson.annotation.JsonIgnore;
import lombok.Getter;
import lombok.Setter;

import javax.persistence.*;
import javax.validation.constraints.NotEmpty;
import java.util.ArrayList;
import java.util.List;

@Entity
@Getter @Setter
public class Member {

    @Id
    @GeneratedValue
    @Column(name = "member_id")
    private Long id;

    @NotEmpty
    private String name;

    @Embedded
    private Address address;

    @JsonIgnore
    @OneToMany(mappedBy = "member")
    private List<Order> orders = new ArrayList<>();
}

엔티티가 Json 변환할 때 @JsonIgnore 애노테이션으로 해당 필드를 제외시킬 수 있다.

Postman으로 조회하기

[
    {
        "id": 1,
        "name": "member1",
        "address": {
            "city": "서울",
            "street": "test",
            "zipcode": "1111"
        }
    },
    {
        "id": 2,
        "name": "member2",
        "address": {
            "city": "부산",
            "street": "qwe",
            "zipcode": "22222"
        }
    }
]

엔티티를 그대로 반환해버리면 엔티티 값만 출력할 수 있다. 추가 다른 값들을 같이 출력할 수 없다.
상황에 따라 유동적으로 변할 수 없다.
이럴 때 V2 버전으로 Result 객체를 따로 만들어서 해결할 것.

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

📌 Member 엔티티

package bookbook.shopshop.domain;

import com.fasterxml.jackson.annotation.JsonIgnore;
import lombok.Getter;
import lombok.Setter;

import javax.persistence.*;
import javax.validation.constraints.NotEmpty;
import java.util.ArrayList;
import java.util.List;

@Entity
@Getter @Setter
public class Member {

    @Id
    @GeneratedValue
    @Column(name = "member_id")
    private Long id;

    @NotEmpty
    private String name;

    @Embedded
    private Address address;

    @OneToMany(mappedBy = "member")
    private List<Order> orders = new ArrayList<>();
}

📌 MemberController

@GetMapping("/api/v2/members")
public Result memberV2() {
    List<Member> findMembers = memberService.findMembers();
    List<MemberDto> collect = findMembers.stream()
            .map(m -> new MemberDto(m.getName()))
            .collect(Collectors.toList());
    return new Result(collect.size(), collect);
}

@Data
@AllArgsConstructor
static class Result<T> {
    private T count;
    private T data;
}

@Data
@AllArgsConstructor
static class MemberDto {
    private String name;
}

엔티티를 DTO로 변환해서 반환한다.
엔티티가 변해도 API 스펙이 변경되지 않는다.
추가로 Result 클래스로 컬렉션을 감싸서 향후 필요한 필드를 추가할 수 있다.

Postman으로 조회하기

{
    "count": 2,
    "data": [
        {
            "name": "member1"
        },
        {
            "name": "member2"
        }
    ]
}

🧷 전체 MemberApiController

package bookbook.shopshop.api;

import bookbook.shopshop.domain.Member;
import bookbook.shopshop.service.MemberService;
import lombok.AllArgsConstructor;
import lombok.Data;
import lombok.RequiredArgsConstructor;
import org.springframework.web.bind.annotation.*;

import javax.validation.Valid;
import java.util.List;
import java.util.stream.Collectors;

@RestController
@RequiredArgsConstructor
public class MemberApiController {

    private final MemberService memberService;

    /**
     * 조회 V1 : 응답 값으로 엔티티를 직접 외부에 노출한다.
     * 문제점
     *  - 엔티티에 프레젠테이션 계층을 위한 로직이 추가된다.
     *    - 기본적으로 엔티티의 모든 값이 노출된다.
     *    - 응답 스펙을 맞추기 위해 로직이 추가된다. (@JsonIgnore, 별도의 뷰 로직 등등)
     *    - 실무에서는 같은 엔티티에 대해 API가 용도에 따라 다양하게 만들어지는데,
     *    한 엔티티에 각각의 API를 위한 프레젠테이션 응답 로직을 담기 어렵다.
     *  - 엔티티가 변경되면 API 스펙이 변한다.
     *  - 추가로 컬렉션을 직접 반환하면 향후 API 스펙을 변경하기 어렵다. (별도의 Result 클래스 생성으로 해결할 수 있다.)
     *
     *  * 결론
     *   - API 응답 스펙에 맞춰 별도의 DTO를 반환해야 한다.
     *   - 안쓰임
     */

    // 조회 V1 : 안좋은 버전, 모든 엔티티가 노출된다.
    @GetMapping("/api/v1/members")
    public List<Member> membersV1() {
        return memberService.findMembers();
    }

    @GetMapping("/api/v2/members")
    public Result memberV2() {
        List<Member> findMembers = memberService.findMembers();
        List<MemberDto> collect = findMembers.stream()
                .map(m -> new MemberDto(m.getName()))
                .collect(Collectors.toList());
        return new Result(collect.size(), collect);
    }

    @Data
    @AllArgsConstructor
    static class Result<T> {
        private T count;
        private T data;
    }

    @Data
    @AllArgsConstructor
    static class MemberDto {
        private String name;
    }

    /**
     * 등록 V1 : 요청 값으로 Member 엔티티를 직접 받는다.
     * 문제점
     *  - 엔티티에 프레젠테이션 계층을 위한 로직이 추가된다.
     *    - 엔티티에 API 검증을 위한 로직이 들어간다. (@NotEmpyt 등등)
     *    - 실무에서는 회원 엔티티를 위한 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);
    }

    /**
     * 등록 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);

    }

    /**
     * 수정 API
     */
    @PutMapping("/api/v2/members/{id}")
    public UpdateMemberResponse updateMemberV2(
            @PathVariable 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;
    }


    @Data
    static class CreateMemberRequest {
        private String name;
    }

    @Data
    static class CreateMemberResponse {
        private Long id;

        public CreateMemberResponse(Long id) {
            this.id = id;
        }
    }


}

👀 참고 자료

https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81%EB%B6%80%ED%8A%B8-JPA-API%EA%B0%9C%EB%B0%9C-%EC%84%B1%EB%8A%A5%EC%B5%9C%EC%A0%81%ED%99%94/dashboard

실전! 스프링 부트와 JPA 활용2 - API 개발과 성능 최적화 - 인프런 | 강의

스프링 부트와 JPA를 활용해서 API를 개발합니다. 그리고 JPA 극한의 성능 최적화 방법을 학습할 수 있습니다., - 강의 소개 | 인프런...

www.inflearn.com