API 개발 기본

2023. 1. 8. 00:54·BackEnd/실전! 스프링 부트와 JPA 활용2

회원 등록 API

회원을 등록하기 위한 API를 만드는 단계이다. 

 

버전 1

@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 CreateMemberResponse {
        private Long id;
        public CreateMemberResponse(Long id) {
            this.id = id;
        }
    }
}

  • @RestController 는 @Controller 와 @ResponseBody를 합친 것 이다.
  • memberService를 @RequiredArgsConstructor로 주입시킨다.
  • PostMapping으로 member를 RequestBody(JSON 타입)으로 받아 멤버를 등록해준다.
  • 그럴 경우 왼쪽 그림 처럼 성공적인 모습을 볼 수 있다.(name이 없어도 등록이 된다. 이걸 방지하기 위해 Member 엔티티에 name에 @NotEmpty를 추가한다.)

문제점

  • 만약 엔티티의 name이 유저 name로 변경되면 이렇게 설계한 경우, API 호출이 불가능해진다. 
  • 실무에서는 회원가입하기 위한 엔티티가 굉장히 여러개 존재할 수 있다. 그러므로 엔티티를 외부에 노출시켜서 회원가입 시키는 것은 매우 않좋은 사례이다.
  • API를 만들때는 엔티티를 매개변수로 받지 말자!!

 

버전 2(정석)

@PostMapping("/api/v2/members")
public CreateMemberResponse saveMemberV2(@RequestBody @Valid CreateMemberRequest request){
    Member member = new Member();
    member.setName(request.getName());
    member.setAddress(request.getAddress());
    Long id = memberService.join(member);
    return new CreateMemberResponse(id);
}

@Data
static class CreateMemberRequest {
    private String name;
    private Address address;
}

  • 버전1과 다른점은 CreateMemberRequest 를 Member 엔티티 대신에 RequestBody와 매핑한다.
  • 엔티티와 프레젠테이션 계층을 위한 로직을 분리할 수 있다.
  • 엔티티와 API 스펙을 명확하게 분리할 수 있다.
  • 엔티티가 변해도 API 스펙이 변하지 않는다.

 

에러사항

회원등록을 하다가 강사님과 다르게 내 table은 auto_incremented가 안 된다는 것을 알 수 있었다.

분명 MemberEntity에 GeneratedValue를 auto로 설정했는데도 말이다.

찾아본 결과 Hibernate5.0 부터 auto가 table을 기본 시퀀스 전략으로 선택한다고 한다. 

해결책은 GenerationType.IDENTITY를 사용하거나 application.properties/yml의 use-new-id-generator-mappings을 false로 설정해야한다.

 

실무에서는 엔티티를 API 스펙에 노출하면 안된다!

 

회원 수정 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 {
    @NotEmpty
    private String name;
}

@Data
@AllArgsConstructor
static class UpdateMemberResponse {
    private Long id;
    private String name;
}

  • PatchMapping을 통해 부분 변경을 실행한다. 이 예제에서는 name만 변경한다. request와 response를 만들어 요청과 응답class를 만든다.
  • 회원 수정하는 update문도 변경가지를 사용해 구현하였다.
  • 변경감지는 변경할 요소를 찾아 영속 컨텍스트로 구한 다음에 거기서 바꾸는 것이다.

 

 

 

 

 

회원 조회 API

버전1

@GetMapping("/api/v1/members")
public List<Member> membersV1(){
    return memberService.findMembers();
}

버전1은 간단하게 응답 값으로 엔티티를 직접 외부에 노출하는 것이다. 이럴 경우 회원 등록 때 처럼 문제가 생긴다.

 

문제점

  • 엔티티에 프레젠테이션 계층을 위한 로직이 추가된다.
  • 기본적으로 엔티티의 모든 값이 노출된다.(비밀번호 값도 노출될 수 잇다)
  • 응답 스팩을 맞추기 위해 여러 로직들이 추가된다.(id와 name이 필요하면 @JsonIgnore등 여러 조직 추가해야한다.)
  • 실무에서는 같은 엔티티에 대해 API가 용도에 따라 다양하게 만들어지는데, 한 엔티티에 각각의 API를 위한 프레젠테이션 응답 로직을 담기는 어렵다.
  • 엔티티가 변경되면 API 스펙이 변한다.
  • 컬렉션을 직접 반환하면 항후 API 스펙을 변경하기 어렵다.

이 문제점을 해결하기 위해서는 API응답 스펙에 맞추어 별도의 DTO를 반환해야 한다.

 

버전2

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

    return new Result(collect);
}

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

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

  • 엔티티를 DTO로 변환해서 반환한다.
  • 엔티티가 변해도 API 스펙이 변경되지 않는다.
  • 추가로 Result 클래스로 컬렉션을 감싸서 향후 필요한 필드를 추가할 수 있다.
  • findMembers는 리스트 형태, stream의 map으로 변경후 collect로 list로 변경 그후 List<MemberDto> 로 반환한다.

 

 

 

출처

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

 

'BackEnd > 실전! 스프링 부트와 JPA 활용2' 카테고리의 다른 글

OSIV와 성능 최적화  (0) 2023.01.11
API 개발 고급 정리  (0) 2023.01.11
컬렉션 조회 최적화  (0) 2023.01.10
지연 로딩과 조회 성능 최적화  (1) 2023.01.08
'BackEnd/실전! 스프링 부트와 JPA 활용2' 카테고리의 다른 글
  • OSIV와 성능 최적화
  • API 개발 고급 정리
  • 컬렉션 조회 최적화
  • 지연 로딩과 조회 성능 최적화
인프라 감자
인프라 감자
  • 인프라 감자
    삶은 인프라
    인프라 감자
  • 전체
    오늘
    어제
    • 분류 전체보기 (243)
      • 클라우드&인프라 (28)
        • 인프라 공부 (4)
        • AWS 구조와 서비스 (18)
        • 클라우드 공부 (4)
        • Terraform (2)
      • AWS Cloud School (13)
        • project (5)
        • Linux, Network (6)
        • Docker (2)
      • BackEnd (162)
        • JAVA 공부 (15)
        • 알고리즘 공부 (71)
        • MySQL 문제 풀기 (8)
        • 스프링 핵심 원리 - 기본편 (18)
        • 스프링 MVC 1편 (4)
        • 자바 ORM 표준 JPA 프로그래밍 (21)
        • 실전! 스프링 부트와 JPA 활용1 (8)
        • 실전! 스프링 부트와 JPA 활용2 (5)
        • 스프링 데이터 JPA (8)
        • Querydsl (4)
      • 혼자하는 프로젝트 (32)
        • 배달의 민족 클론코딩 (7)
        • 나만의 프로젝트 (10)
        • 스프링 부트로 구현한 웹 (15)
  • 블로그 메뉴

    • 홈
    • 태그
    • 방명록
  • 링크

    • Email
    • GitHub
  • 공지사항

  • 인기 글

  • 태그

    프로그래머스
    dp
    완전탐색
    자바
    이것이 자바다
    VPN
    스프링 핵심 원리-기본편
    유니온 파인드
    네트워크 기본 용어
    자동 배포
    정렬
    다이나믹 프로그래밍
    쿼드 압축
    linux
    중첩 선언
    백트래킹
    상속
    조합
    querydsl
    디팬스 게임
  • 최근 댓글

  • 최근 글

  • hELLO· Designed By정상우.v4.10.3
인프라 감자
API 개발 기본
상단으로

티스토리툴바