API 개발 기본

JPA 사용하면서 API를 만들어 보자

회원 등록 / 수정 / 삭제

POSTMAN 설취

컨트롤러 / API 쪽 따로 구분

api 공통처리 가 따로 나감? 등.. 이런 이유로 패키지 분리

회원 등록

@Valid
@NotEmpty

중요한값은 벨리드 -> notEmpty 이런식으로 검증 해주자

여기서 문제점

-> 단순한 등록이지만
프레젠테이션에서(화면)의 검증로직이 MemberEntity에 들어가 있다.
엔티티의 name -> userName 으로 바꾸면?
entity의 스펙이 바뀌어서 큰 문제가 생김.

MemberEntity 자체를 쓰면 생기는 문제..

결론적으로 API의 스펙을 위한 DTO 를만들어야됨
엔티티를 컨트롤러에서 바인딩으로 받으면 안됌 궁극적으로 큰 장애가 발생함.

바꿔서 --->>>

장점 : API 스펙을 바꿔도 값을 변하는 시점에서 변경 하면 됨으로 api 영향 안받음
v1은 파라미터가 뭐가 올지 몰라서 문서를 보지않는 이상 Api 스펙 확인 어려움
V2는 그냥 name만 들어 오는 거구나 이해하기 쉬움
그리고 벨리데이션 하고싶으면 CreateMemberRequest에 notEmpty 이런식 추가해
주면 됨. 유지보수하기 쉬움
V2처럼 만드는게 api 정석 .

  -> DTO로 들어오고 나가는것으로 ..

회원 수정 API

PUT 함수

회원 조회 API

일단 데이터 변경안돼게 None 으로 설정

반복적으로 데이터 삭제되면 넣기 귀찮아서

불필요한 Orders 객체가..

요렇게 빠지게 된다.

하지만 요구사항이 다양하기 때문에 엔티티안에 이런거를 넣기 시작하면

문제가 됨.. 엔티티의 프레젠테이션 로직이 또 들어가 버림...
이렇게 되면 엔티티랑 양방향 의존관계가 되버림..

그래서 ?

추가로 컬렉션을 반환하면 (Array)
만약에 count를 넣어 달라하면? json 스펙이 확장이 어려움

V2로 개선 시작.

정말 필요한 것만 노출시키자.

이런식으로 확장