회원 수정 API

회원 수정 메서드 : PUT url : /api/vx/members/{id}

RESTful API 검색하면 API 설계할 때 어떤 스타일로 설계하는 것이 RESTful API인지 나온다! PUT은 멱등하다. 똑같은 작업을 반복해도 변하지 않기 때문에 name을 new-hello로 바꾸는 같은 작업을 여러번 해도 결과는 똑같다. 전체 업데이트를 사용하는 것이 맞다. 부분 업데이트를 하려 Patch 또는 POST 를 사용하는 것이 REST 스타일에 맞다.

회원 등록 시 사용했던 DTO를 그대로 사용해도 될 것 같지만, 회원 등록과 회원 수정은 API Specification이 다르고, 회원 수정은 한번 등록하면 좀 제한적이기 때문에 별도의 DTO를 생성하는 것이 좋다.

DTO는 데이터 통신용이라 로직이 있는 것도 아니여서 실용적인 관점에서 롬복 애노테이션 막 쓴다고 함. 롬복의 @AllArgsConstructor로 DTO의 모든 필드들을 생성자를 자동 생성해준다!

MemberService에 update 메서드 추가 : 반환 데이터는 없다.(void) =>Member를 반환해도 되지만 이것은 영속성 상태가 끝난 엔티티다. 강사님 개인 스타일 : 커맨드와 쿼리를 철저하게 분리한다. Member를 반환하면 업데이트하면서 결국 Member를 쿼리해버리는 꼴이 된다. update는 변경성 메서드인데 id로 Member를 조회하는 꼴이 된다. =>커맨드와 쿼리가 같이 있는 꼴이 된다. 그래서 update메서드 같은 수정하는 것들은 변경만하고 void로 아무것도 리턴하지 않고 끝내버린다!또는 id값 정도만 반환한다. =>유지보수 증대된다!

MemberService에 변경 감지를 사용해서 데이터를 수정한다! @Transactional, 영속성 컨텍스트 관리대상

@Transactional//변경감지
public void update(Long id, String name) {
    Member member = memberRepository.findOne(id);//영속성 컨텍스트에서 먼저 찾고, 없으면 DB에서 가져온다.
    member.setName(name);//영속상태의 member의 name을 바꿔주면 스피링 AOP가 동작하면서 @Transactional 애노테이션에 의해 트랜잭션 관련 AOP 끝나는 시점에 트랜잭션이 커밋된다.
    //그 때 JPA가 DB에 flush하면서 영속성 컨텍스트의 것들을 커밋한다!
}

회원 수정 API : 회원 수정 DTO(요청, 응답) DTO를 요청 파라미터에 매핑!

@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
  class UpdateMemberResponse {
      private Long id;
      private String name;
  }

Postman으로 확인

PUT으로 데이터 수정(전송)

1. 클라이언트 : "name=hello", api/v2/members_2

2. 서버 : id값 받음.

3. /api/v2/members/{id} 로 접속시 put으로 변경할 name으로 데이터 수정 요청.