<aside> ❗

템플릿 엔진에서 사용하는 컨트롤러랑

API 스타일의 컨트롤러 패키지를 분리

→ 공통 예외처리할 때, 패키지나 구성 단위로 공통 처리 많이 수행하기 때문

→ 화면은 공통 화면 에러 페이지가 등장해야 함

→ API는 공통 에러용 JSON 스펙이 나가야 한다.

</aside>

<aside> ❗

@RestController

• @Controller + @ResponseBody - REST API 사용할 때 사용
• @ResponseBody - 데이터 자체를 JSON이나 XML로 반환할 때 사용하는 어노테이션

@Valid - 스프링이 검증을 수행함(jakarta)

• 필수 값인 필드에는 @NotEmpty 애너테이션을 붙여주면 된다.
• 해당 값이 없으면 에러 메시지가 출력된다. (기본값 출력)

@NotEmpty
private String name;

PostMan

• postMan에서 서버로 데이터를 전송할 때, JSON 타입을 Body에 담아서 전송 또한, Header에 Content-Type을 application/json으로 설정되어 있어야 한다. </aside>

<aside> ❗

DTO를 사용해야 하는 이유

• 엔티티를 그대로 사용할 경우 프레젠테이션(컨트롤러) 계층을 위한 검증 로직이 엔티티에 다 들어가게 됨
  • 어떤 API에서는 @NotEmpty가 필요하지 않을 수 있음
  • 엔티티의 스펙을 name에서 username으로 변경한 경우
    API 스펙 자체가 변경됨
  • 엔티티는 많은 곳에서 사용하므로 바뀔 확률이 높음 → API 스펙이 자주 바뀌어져 문제가 발생할 수 있음

API 스펙을 위한 별도의 DTO를 만들어야 함 → 큰 장애 발생

• api를 만들 때는 항상 엔티티를 파라미터로 받지 말것
• 또한 엔티티를 외부에 노출하면 안 된다. </aside>

실습 1

<aside> ❗

V1

@PostMapping("/api/v1/members")
public CreateMemberResponse saveMemberV1(@RequestBody @Valid Member member) {
	Long id = memberService.join(member);
	return new CreateMemberResponse(id);
}

• 엔티티를 RequestBody에 직접 매핑

[문제점]

• 엔티티에 프레젠테이션 계층을 위한 로직이 추가 됨
  • 엔티티에 API 검증을 위한 로직이 들어간다.
  • 실무에서는 회원 엔티티를 위한 API가 다양하게 만들어지는데, 한 엔티티에 각각의 API를 위한 모든 요청 요구사항을 담기 어려움
• 엔티티가 변경되면 API 스펙이 변한다.
• 개발자 입장에서 엔티티만 보고 어떤 데이터가 들어올지 예측할 수 없다. → API 문서를 항상 확인해야 함
• 엔티티를 외부에 노출하지 않는 것이 좋다.

요청이 들어오고 나갈 때, 절대 엔티티를 사용하지 마라

→ **항상 DTO를 사용**할 것

</aside>

<aside> ❗

V2

@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 스펙이 변하지 않는다.

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

</aside>

<aside> ❗

회원 수정

• put - 멱등 - 같은 것을 여러 번 호출해도 결과가 똑같다.
• 엔티티에는 Lombok을 getter 말고 잘 사용하지 않음 DTO에는 Lombok을 막 사용한다.
• update 메서드가 끝날 때, 스프링 AOP가 동작하면서 트랜잭셔널 어노테이션에 의해서 트랜잭션 AOP가 끝나는 시점에 커밋이 되는데 그 때, flush()하여 영속성 컨텍스트의 변경 내용을 DB에 반영

@Transactional
    public void update(Long memberId, String updateName) {
        // 영속화
        Member findMember = memberRepository.findOne(memberId);
        // 값 수정
        findMember.setName(updateName);
    }

• 커멘드(쓰기)와 쿼리(조회)를 철저히 분리하기 우해서 update메서드에서 member를 반환하지 않도록 함(영한님 스타일) → 유지 보수 관점에서 더 좋다.

@PutMapping("/api/v2/members/{id}")
    public UpdateMemberResponse updateMemberV2(
            @RequestBody @Valid UpdateMemberRequest request,
            @PathVariable("id") Long id) {

        memberService.update(id, request.getName());
        Member one = memberService.findOne(id); // 트래픽 많지 않으면 이슈가 되지 않음
        return new UpdateMemberResponse(one.getId(), one.getName());
    }

• 이를 분리하기 위해서 조회 메서드를 한 번 더 호출 → 트래픽이 많지 않으면 이슈가 되지 않음 </aside>

<aside> ❗

조회 실습

V1

@PostMapping("/api/v1/members")
public CreateMemberResponse saveMemberV1(@RequestBody @Valid Member member) {

	Long id = memberService.join(member);
	return new CreateMemberResponse(id);
}

[문제점] - 응답 값으로 엔티티를 직접 외부에 노출

• 엔티티에 프레젠테이션 계층을 위한 로직이 추가된다. @JsonIgnore 등등
• 기본적으로 엔티티의 모든 값이 노출된다. password도 노출될 수 있음 (막을 수 있지만, 다른 API에서는 password가 필요할 수 있음)
• 응답 스펙을 맞추기 위해 로직이 추가된다. ( @JsonIgnore, 별도의 뷰 로직 등등)
• 실무에서는 같은 엔티티에 대해 API가 용도에 따라 다양하게 만들어지는데, 한, 엔티티에 각각의 API를 위한 프레젠테이션 응답 로직을 담기는 어렵다.
• 엔티티가 변경되면 API 스펙이 변한다. name → username 변경 시, 요청자도 변경해야 함
• 추가로 컬렉션을 직접 반환하면 향후 API 스펙을 변경하기 어렵다. (별도의 result 클래스 생성으로 해결 ) ”count”: 2, “member”:[ … ] 형태로 변경 불가

[결론]

• API 응답 스펙에 맞추어 별도의 DTO를 반환한다.
• 엔티티를 수정하더라도 API 스펙이 바뀌지 않는다.
• 노출하고 싶은 것만 스펙에 노출할 수 있다. </aside>

<aside> ❗

V2

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

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

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

• 단순히 List를 API 응답으로 반환하는 경우, 유연성이 전혀 없다. ”collect” : { … } 형태로 반환되므로 추가적인 데이터 전달이 어려움
• Result와 같은 클래스를 만들어 List를 감싸줌으로써 이를 해결 ”result” : { “count”: 2,. “collect” : { … } }

[결론]

• 엔티티를 DTO로 변환해서 반환한다.
• 엔티티가 변해도 API 스펙이 변경되지 않는다.
• 추가로 Result 클래스로 컬렉션을 감싸서 향후 필요한 필드를 추가할 수 있다. </aside>