강의 목표
- 등록, 수정, 조회 REST API 개발
- API 개발 실무 노하우
=> JPA 기능 구현 + 성능 최적화
API 개발 기본
화면을 서버에서 템플릿 엔진을 통해 렌더링하여 HTML을 내리는 것이 아닌,
싱글 페이지, view.js, react을 통해 클라이언트 쪽에서 프론트엔드 엔지니어가 해결하는 경우가 많다.
백 단에서는 MS Architecture, Mobile Application의 영향에 따라 API를 통해 통신하는 경우가 늘어나고 있다.
JPA를 사용하면서 API를 개발하는 것은 기존의 SQL 방식을 사용할 때와는 다른 차원의 문제가 발생한다.
postman 설치 (https://www.getpostman.com)
회원 등록 API
템플릿 엔진을 통해 컨트롤하는 컨트롤러와 API와 통신하는 컨트롤러는 패키지를 분리하는 것이 좋다.
공통으로 예외처리를 할 때 패키지 단위로 많이 하는데 템플릿 엔진과 API는 예외처리 방식에 있어 차이가 있다.
템플릿 엔진에서는 문제가 생기면 화면(html)에 출력하나 API는 공통 에러용 json api를 출력해야 한다.
@Controller + @ResponseBody = @RestController
Rest API 개발을 위한 컨트롤러
@ResponseBody: 데이터 자체를 json이나 xml로 보냄
V1 엔티티를 Request Body에 직접 매핑
문제점
엔티티에 프레젠테이션 계층을 위한 로직이 추가된다.
엔티티에 API 검증을 위한 로직이 들어간다. (@NotEmpty 등등)
실무에서는 회원 엔티티를 위한 API가 다양하게 만들어지는데, 한 엔티티에 각각의 API를 위한 모든 요청 요구사항을 담기는 어렵다.
엔티티가 변경되면 API 스펙이 변한다.
결론
API 요청 스펙에 맞추어 별도의 DTO를 파라미터로 받는다
*참고: 실무에서는 엔티티를 API 스펙에 노출하면 안된다.
실무에서는 member 엔티티의 데이터가 필요한 API가 계속 증가하게 된다. 어떤 API는 name 필드가 필요하지만, 어떤 API는 name 필드가 필요없을 수 있다. 결론적으로 엔티티 대신에 API 스펙에 맞는 별도의 DTO를 노출해야 한다
V2 엔티티 대신에 DTO를 RequestBody에 매핑
엔티티와 프레젠테이션 계층을 위한 로직을 분리할 수 있다.
엔티티와 API 스펙을 명확하게 분리할 수 있다.
- API 스펙에 맞게 필드에 Validation 추가
- API request를 통해 어떤 데이터가 들어오는지 확인 가능
엔티티가 변해도 API 스펙이 변하지 않는다.
회원 수정 API
회원 수정 API updateMemberV2 은 회원 정보를 부분 업데이트 한다. 여기서 PUT 방식을 사용했는데, PUT은 전체 업데이트를 할 때 사용하는 것이 맞다. 부분 업데이트를 하려면 PATCH를 사용하거나 POST를 사용하는 것이 REST 스타일에 맞다.
수정은 등록과 달리 범위가 제한적이기 때문에 다른 등록과 다른 DTO 사용
변경 감지를 사용해서 데이터를 수정
*쿼리(조회)와 커맨드(변경)의 분리: 데이터 수정 메서드에서 직접 엔티티를 반환(준영속 엔티티가 됨)하기 보다, 아무것도 반환하지 않거나 필드 값 정도만 반환하여 엔티티를 사용하는 곳에서 직접 조회하도록 한다. -> 유지 보수성 증대
조회: Transaction 필요X
변경: Transaction 필요O
회원 조회 API
회원조회 V1: 응답 값으로 엔티티를 직접 외부에 노출
API가 필요로 하지 않는 필드는 @JsonIgnore
문제점
엔티티에 프레젠테이션 계층을 위한 로직이 추가된다.
기본적으로 엔티티의 모든 값이 노출된다.
응답 스펙을 맞추기 위해 로직이 추가된다. (@JsonIgnore, 별도의 뷰 로직 등등)
실무에서는 같은 엔티티에 대해 API가 용도에 따라 다양하게 만들어지는데, 한 엔티티에 각각의 API를 위한 프레젠테이션 응답 로직을 담기는 어렵다.
엔티티가 변경되면 API 스펙이 변한다.
추가로 컬렉션을 직접 반환하면 항후 API 스펙을 변경하기 어렵다.(별도의 Result 클래스 생성으로 해결)
결론
API 응답 스펙에 맞추어 별도의 DTO를 반환한다.
회원조회 V2: 응답 값으로 엔티티가 아닌 별도의 DTO 사용
엔티티가 변해도 API 스펙이 변경되지 않는다.
추가로 Result 클래스로 컬렉션을 감싸서 향후 필요한 필드를 추가할 수 있다.
*API 스펙과 DTO가 1:1
