Ch01. API 개발 기본 - 회원 등록 API

postman 설치 (https://www.getpostman.com)

• Api랑 화면을 로딩해 주는 화면과는 분리를 해주는 것이 좋다.

RestController

@RestController //2개의 어노테이션을 합친것이다.
@RequiredArgsConstructor
public class MemberApiController {

    private final MemberService memberService;

    @PostMapping("/api/v1/members")
    public CreateMemberResponse saveMemberV1(@RequestBody @Valid Member member){
        //@RequestBody -> json객체를 member에 넣어준다
        //Controller 에서 Validation 을 하고 싶으면 @Valid를 붙힌뒤, 어노테이션을 달아주면 된다.
        Long id = memberService.join(member);
        return new CreateMemberResponse(id);
    }

    @Data
    static class CreateMemberResponse{
        private Long id;

        public CreateMemberResponse(Long id) {
            this.id = id;
        }
    }
}

• V1 엔티티를 Request Body에 직접 매핑
• 문제점
  • 엔티티에 프레젠테이션 계층을 위한 로직이 추가된다.()
  • 엔티티에 API 검증을 위한 로직이 들어간다. (@NotEmpty 등등)
  • 실무에서는 회원 엔티티를 위한 API가 다양하게 만들어지는데, 한 엔티티에 각각의 API를 위한 모든 요청 요구사항을 담기는 어렵다.
  • 엔티티가 변경되면 API 스펙이 변한다.
• Entity에 Validation 검증 로직이 들어가 있으므로 문제
• Entity의 스펙을 변경하게 되면 API을 스펙이 변경이 된다(가장 큰 문제)
• API랑 Entity가 1-1로 매핑이 되어 있으므로 문제가 발생한 것이다.
• Entity의 속성이 변경되면, 사이드 임팩트가 어디까지 퍼지는지 분석이 안된다.

결론

• API 요청 스펙에 맞추어 별도의 DTO를 파라미터로 받는다 

안전한 API

• Entity로 바인딩되어 있다면, 존재하는 속성들을 다 받을 수 있기 때문에 어떤 파라미터를 채워야 하는지 한눈에 알 수 없다.(따라서 API 스펙에 맞는 Request를 만드는 게 정석이다)
• 엔티티와 프레젠테이션 계층을 위한 로직을 분리할 수 있다.
• 엔티티와 API 스펙을 명확하게 분리할 수 있다.
• 엔티티가 변해도 API 스펙이 변하지 않는다.
• 참고: 실무에서는 엔티티를 API 스펙에 노출하면 안 된다!