[스프링 부트와 JPA 활용2 - API 개발과 성능 최적화] 1. API 개발 기본 - 회원 API

• @RestController : @Controller + @ResponseBody(데이터를 json이나 xml로 보냄)
• @RequestBody : json 데이터를 member에 매핑해 넣어줌
• @Valid : javax validation 자동으로 수행

 

MemberApiController

회원 등록 API

@PostMapping("/api/v1/members")
public CreateMemberResponse saveMemberV1(@RequestBody @Valid Member member) {
    //@RequestBody -> json 데이터를 member에 매핑해 넣어줌, @Valid -> javax validation 자동으로 수행
    Long id = memberService.join(member);
    return new CreateMemberResponse(id);
}

V1 엔티티를 Request Body에 직접 매핑시 문제점

• 엔티티에 프레젠테이션 계층을 위한 로직이 추가된다.
• 엔티티에 API 검증을 위한 로직이 들어간다. (@NotEmpty 등등)
• 실무에서는 회원 엔티티를 위한 API가 다양하게 만들어지는데, 한 엔티티에 각각의 API를 위한 모든 요청 요구사항을 담기는 어렵다.

 

Entity를 Request로 사용할 경우

→ Entity를 손대면 api 스펙 자체가 변화함, 어떤 값이 넘어오는지 알기 힘듦

→ 큰 장애 발생

 

API 요청 스펙에 맞춰서 별도의 dto를 파라미터로 받기!

→ 엔티티를 변경해도 API 스펙이 변하지 않는다!

→ API 스펙에 맞게 dto를 변경시키면 된다.

@PostMapping("/api/v2/members") // Request, Response 별도의 객체 만듦
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;
}

@Data
static class CreateMemberResponse {
    private Long id;
    
    public CreateMemberResponse(Long id) {
        this.id = id;
    }
}

• CreateMemberRequest 를 Member 엔티티 대신에 RequestBody와 매핑
• 엔티티와 프레젠테이션 계층을 위한 로직 분리 가능
• 엔티티와 API 스펙을 명확하게 분리
• 엔티티가 변해도 API 스펙이 변하지 x

 

 

회원 수정 API

@PatchMapping("/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 // dto에서는 lombok 어노테이션 많이 쓰는 편
static class UpdateMemberResponse {
    private Long id;
    private String name;
}

MemberService

@Transactional // 커맨드와 쿼리 분리
public void update(Long id, String name) {
    Member member = memberRepository.findOne(id);
    member.setName(name);
}

회원 수정 API updateMemberV2 은 회원 정보를 부분 업데이트

• PUT 방식을 사용했는데, PUT은 전체 업데이트를 할 때 사용
• 부분 업데이트를 하려면 PATCH를 사용하거나 POST를 사용하는 것이 REST 스타일에 맞음

 

 

회원 조회 API

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

@GetMapping("/api/v1/members")
public List<Member> membersV1() { // 엔티티의 정보들이 외부에 노출됨 -> 문제
    return memberService.findMembers();
}

모든 엔티티가 노출되는 문제 → API 응답 스펙에 맞추어 별도의 DTO를 반환한다.

• @JsonIgnore : Json에서 정보를 빼고 보여줄 수 있음(최악)

 

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

@GetMapping("/api/v2/members")
public Result memberV2() {
    List<Member> findMembers = memberService.findMembers();
//    for (Member findMember : findMembers) {
//        new MemberDto(findMember.getName());
//    }
    List<MemberDto> collect = findMembers.stream()
            .map(m -> new MemberDto(m.getName())) // 조건에 해당하는 값으로 변환
            .collect(Collectors.toList()); // 리스트로 리턴 받기

    return new Result(collect);
}

@Data
@AllArgsConstructor
// data로 한번 감싸줘야 함 -> List를 바로 내보내면 JSON 배열 타입으로 나감 -> 유연성 떨어짐
static class Result<T> {
    private T data;
}

@Data
@AllArgsConstructor
static class MemberDto { // 내가 노출할 것만
    private String name;
}

 

 

 

 

 

 

참고 강의 :

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