API 개발 기본

엔티티를 파라미터로 받을 경우의 문제

 

컨트롤러

엔티티

• 검증을 위한 @NotEmpty같은 로직들이 엔티티에 추가된다.
• 엔티티를 위한 매우 다양한 API가 만들어지는데, 한 엔티티에 각각의 API를 위한 요구사항들을 담기는 어려움
• 가장 큰 문제는 엔티티가 변경되면 API 스펙 자체가 변한다.

만약 엔티티의 name필드가 username으로 변경된다면 API 스펙 자체가 변하기 때문에 큰 문제가 발생한다.

 

API 요청 스펙에 맞춰 별도의 DTO클래스를 만들어 DTO 객체를 파라미터로 받아야한다.
절대 파라미터로 엔티티를 바로 받지 말자!!
엔티티를 API 스펙에 노출 X

 

• 이와 같이 따로 DTO 클래스를 만들어 파라미터로 받아야한다.
• 예제를 위해 setter를 사용했지만 실제는 사용 X
• 엔티티와 표현 계층을 위한 로직을 분리할 수 있다. @NotEmpty를 DTO에 넣어줄 수 있음.
• 엔티티와 API 스펙을 명확하게 분리할 수 있다.
• DTO 클래스를 보고 어떤 것이 파라미터로 넘어오는지 명확하게 알 수 있다.
• 엔티티가 변해도 API 스펙이 변하지 않는다.

postman을 통해 실제 요청을 전송

 

---

엔티티에는 getter만 쓰는 것이 좋고 DTO에는 setter등등 여러가지를 사용해도 괜찮다.(실용적인 면으로)

 

전체 업데이트를 할때는 PUT, 부분 업데이트는 PATCH or POST

 

 

조회 API

 

 

• 이 또한 엔티티가 응답 값으로 외부에 직접 노출되었다.
• 요청한 정보는 회원 정보인데, 주소와 주문 정보까지 노출되는 심각한 문제가 발생한다.
• 별도의 DTO 클래스를 사용해야함.
• 컬렉션(List)을 직접 반환하면 향후 API 스펙을 변경하기 어렵다.
• 응답 스펙을 맞추기위해 엔티티에 @JsonIgnore등의 별도의 로직이 추가되는 문제

 

엔티티를 노출해선 안된다!

 

• DTO 클래스를 사용하고 컬렉션을 바로 반환하는 것이 아니라 별도의 클래스로 감싸서 향후 필요한 필드를 추가할 수 있도록 해야한다.