[스프링 부트와 JPA 활용 2] 1. API 개발 기본

📌 1. 회원 등록 API

⚡ V1 엔티티를 Request Body에 직접 매핑

package jpabook.jpashop.api;
 import jpabook.jpashop.domain.Member;
 import jpabook.jpashop.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;

     @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;
        } 
    }
}

✔ @ResponseBody

• Spring MVC에서 사용되는 어노테이션
  •  메소드에서 반환되는 값을 HTTP 응답 본문(body)에 직접 작성하도록 지시
• 반환값이 View를 거치지 않고 HTTP 응답데이터로 직접 전송

✔ @Valid

• Bean Validation API 어노테이션
  • 주로 Spring Controller 메소드의 파라미터에 사용됨
• Spring이 자동 검증해줌

✔ @Data

• Lombok 라이브러리에서 제공하는 어노테이션 -> 클래스에 대한 기본적인 메소드 자동 생성
  • @Getter, @Setter, @RequiredArgsConstructor, @ToString, @EqualsAndHashCode 포함

✔ 등록 V1: 요청 값으로 Member 엔티티를 직접 받음

• 문제점
  • 엔티티에 프레젠테이션 계층을 위한 로직이 추가됨
  • 엔티티에 API 검증을 위한 로직이 들어감(@NotEmpty 등등)
  • 실무에서는 회원 엔티티를 위한 API가 다양하게 만들어지는데, 한 엔티티에 각각의 API를 위한 모든 요청 요구사항을 담기는 어려움
  • 엔티티가 변경되면 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 스펙이 변하지 않음

 

cf) 실무에서는 엔티티를 API 스펙에 노출하면 안됨

 

 

📌 2. 회원 수정 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);
    }
}

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

 

PUT -> 전체 업데이트할 때 사용
PATCH -> 부분 업데이트를 할 때 사용

 

 

 

📌 3. 회원 조회 API

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

package jpabook.jpashop.api;

@RestController
@RequiredArgsConstructor
public class MemberApiController {

    private final MemberService memberService;


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

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

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

 

cf) 엔티티를 외부에 노출하지 마라!!!!

 

 

✔ 실무에서는 member 엔티티의 데이터가 필요한 API가 계속 증가됨

• 어떤 API는 name필드가 필요하지만, 어떤 API는 name필드가 필요 없을 수도 있음
  •  엔티티 대신에 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 클래스로 컬렉션을 감싸서 향후 필요한 필드를 추가할 수 있음

 

 

<실전! 스프링 부트와 JPA 활용2 - API 개발과 성능 최적화_김영한>을 수강하고 작성한 글입니다

 

 

 

 

 

 

---

NEXT

[스프링 부트와 JPA 활용 2] 2. API 개발 고급 - 조회용 샘플 데이터 입력