2. 회원 수정 API

수정같은 거 할 때 사용하는 용도의 http 메소드가 

put

https://qwefdg3.tistory.com/190

장점이 멱등하다고 표현하는데, 캐시같은 거임.

같은 요청 계속 보내도 똑같은 내용이면 처리 안함.

 

@PutMapping("api/v2/members/{memberId}")
public UpdateMemberResponse updateMemberV2(
        @PathVariable("memberId") Long id,
        @RequestBody @Valid UpdateMemberRequest request){
    memberService.update(id, request.getName());
    Member findMember = memberService.findOne(id);
    return new UpdateMemberResponse(findMember.getId(), findMember.getName());
}

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

@Data
static class UpdateMemberRequest{
    private String name;
}

@PathVariable로 받아서 그걸 가지고 update한다.

@Transactional
public void update(Long id, String name){
    Member findMember = memberRepository.findOne(id);
    findMember.setName(name);
}

이렇게 update한다.

여기서 return으로 저 findMember를 넘겨줘도 되지만, CQRS 패턴 이란 것이 있다.

이게 뭐냐면 커맨드성이랑 쿼리를 분리한다는 건데,

커맨드가 CUD, 쿼리를 R 이라고 한다.

커맨드인 update랑 쿼리인 조회, R을 분리했다.

이렇게 하면 select 쿼리가 2번 나가게 되는 꼴이긴 하지만, 그렇게까지 많은 리소스를 잡아먹진 않기 때문에 이렇게 하는 방식을 영한님은 선호하신다고 하셨다.

유지보수에 좋다고 하셨다.

조회와 변경부분을 분리.

 

그리고 UpdateMemberResponse나 UpdateMemberRequest를 따로 만든 이유는 보통 update의 경우 일부분만 바꾸기 때문에 스펙이 다르다. 그래서 따로 만들었다.

 

또 이렇게 Dto부류의 객체는 데이터 전달 역할이 주이기에 따로 크게 데이터 무결성에는 아무래도 그 크게 엔티티보다 중요하지는 않아서, 저런 식으로 저런 @Data같은 애노테이션을 막? 쓰기도 한다는 모양이다.

 

다른 거 였으면 거의 @Getter는 무조건 쓰고, 나머진 상황에 따라.

 

그리고, Update 관련 Dto부류도 여기 컨트롤러에서만 쓸꺼기 때문에 inner 클래스로 함.