[JPA+SpringBoot] 엔티티를 API에 노출했을 때 발생할 수 있는 문제점과 해결방법

 

1. 엔티티를 API에 노출하는 방법을 사용한다면 안되는 이유

-엔티티에 프레젠테이션 계층을 위한 로직이 추가된다

-엔티티에 API 검증을 위한 로직(@NotEmpty)이 들어간다

이는 엔티티에 validation을 위한 로직을 포함하는 것이다 

-실무에서는 회원 엔티티를 위해 다양한 API가 만들어지는데, 한 엔티티에 각 API의 모든 요청 요구사항을 담기는 어렵다

-엔티티가 변하면 API 스펙이 변한다(가장 큰 문제점)

 

-엔티티를 파라미터로 받아서 사용하는 saveMemberV1 메소드

@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;
              
     } 
}

---> 엔티티를 파라미터로 받지 말자. 엔티티를 노출해서도 안된다 

2. 위 문제를 해결하는 방법

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

CreateMemberRequest를 Member 엔티티 대신에 RequestBody와 매핑한다

 

이렇게 하면, 

엔티티와 프레젠테이션 계층을 위한 로직을 분리할 수 있다

엔티티를 변경해도 API 스펙이 변하지 않는다 

엔티티와 API 스펙을 명확하게 분리할 수 있다 

@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);
          
}

@Data
    static class CreateMemberRequest {
        private String name;
    }
    
@Data
static class CreateMemberResponse { 
	private Long id;
    public CreateMemberResponse(Long id) {
    	this.id = id;                 		 
}