API 개발

[ 설명 ]

: 템플릿 엔진을 통해 뷰를 내려주는 것이 아닌 REST API로 데이터만 내려주는 것

• 최근 React, Vue등 클라이언트에서 렌더링을 통한 방식을 대부분 사용
• API를 개발하는 방식의 서버 개발을 실무로 하는 경우가 더 많음

[ 기본 ]

• 컨트롤러 구조 나누기
  • 템플릿 엔진을 사용한 개발과 혼용해서 사용할 경우 컨트롤러 구조를 따로 유지
    --> 줄 수 있는 데이터 자체가 다르기 때문에

• DTO를 적극 활용 (필수)
  • HTTP Request / Response 를 API에 맞춰 DTO로 사용하자
  • Entity를 직접 반환하면 Entity 변경시 API 스펙이 변경된다
  • 기본적으로 Entity의 모든 값이 노출됨
  • 필요한 데이터를 거르기 위해 필드에 @JsonIgnore을 쓰는 것은 바람직하지 X
    : Entity에 API 스펙에 맞추기 위한 코드가 추가되고 유지되어 버림
  • Entity에 Presentation 계층의 로직이 있는것은 바람직하지 X
  • 컬렉션을 직접 반환하면 향후 API스펙을 확장 / 변경하기 어려움

• Entity 직접 반환시 무한루프에 걸릴 수 있음
  • json형식으로 반환하기 위한 과정이 수행될 때 Entity의 양방향 연관관계에 의해서 서로 무한 참조가 일어나버린다
  • Entity를 직접 반환하지 말고 DTO를 생성해 반환하면 된다

[ 회원 가입 ]

(API 로직)

• /api/v1/members
  • 회원가입 version 1
  • @RequestBody를 통해 데이터를 바로 매칭함
  • Response는 DTO를 사용 / Request는 Entity로 직접 받음
• /api/v2/members
  • 회원가입 version 2
  • Response / Request 모두 DTO를 사용
    --> 표현계층과 Entity계층을 분리 + 필요한 데이터만 사용

---

(DTO)

[ 회원 수정 ]

(API 로직)

• /api/v2/members/{id}
  • @PathVariable() 을 통해 params를 추출
  • Request / Response 모두 DTO를 사용
  • memberService.update는 변경 감지를 이용한 수정으로 구현
  • 입력한 id로 한번 검색해서 주는 것으로 확인 가능!

---

(DTO)

---

(변경 감지 수정 로직)

• 식별자를 파라미터로 받은 후 영속성 컨텍스트가 관리하게 한 후 수정!

[ 전체 회원 조회 ]

(API 로직)

• /api/v1/members
  • Entity를 직접 반환
    --> 매우 위험 (실무 사용 X)
• /api/v2/members
  • DTO 사용
  • map을 활용해서 List<DTO> 형식으로 변경
  • Result<T> 를 사용해서 반환 데이터에 확장성 추가

---

(DTO)

• Result<T>를 통해 필요한 데이터가 있을 때 확장이 용이함