- 패키지 구조 → domain 밑에 repo, service, controller .. 를 파는게 좋은지? 아니면 도메인끼리 다 묶어두는게 좋은지
- ClubCategory에서 club_id, category_id를 복합키로 사용하는 것이 좋은지, 아니면 둘중하나를 기본키로 설정하는 것이 가능한지, 가능하다면 좋은지, 아니면 새로운 기본키를 설정하는 것이 좋은지 궁금하다.
- 기본적으로 entity와 repository는 1대1 매핑인지?
@Repository안달아도 bean 설정됨?- 현욱이형
JwtAuthenticationFilter에 왜 @Service 붙인건지? @Component가 맞는거 같아서 난 그렇게함.
.requestMatchers("/").permitAll() // health check 이거 왜 넣은건지? 이거 쓰고 / 경로로 요청 보내면 그냥 403 뜨는데, 원래 white label 떠야하는거 아닌지? → 이건 나중에 로그로 찍어보자- TokenAccessDeniedHandler는 Bean 등록을 하고, RestAuthenticationEntryPoint은 Bean 등록을 하지 않는 이유.
- Dto to Entity 로직 구현을 어디에 해야함? club 생성시 고민이 생김
ClubRoleApplication savedClubRoleApplication = clubRoleApplicationRepository.findById(clubRoleApplication.getId()) .orElseThrow(() -> new NoSuchElementException("clubRoleApplication not found"));
- 꼭 이렇게 해야하는 건지? 그냥 flush 해줘야 하는건지
- Get요청으로, 요청리스트를 불러올 때, Path Variable vs Query Parameter를 사용하지 않고, body에 clubId를 받아오게 설계하였는데, 언제 url에 id를 지정하는 것이 좋은건지? 내 생각엔 club id가 노출되니까 안좋은거 같은데
- Controller와 Service 메소드명 계속 겹치는데 ㄱㅊ은가?
- http 메소드 중 Post, Patch, Put, Delete, Get이 있는데, 궁금한게 POST 요청으로 보낸다면, 반드시 리소스가 생성되도록 설정되는건지? 아니면, 거기 앞단은 그냥 규약이고 service에서 repository.delete()메소드를 수정해도 작동은 되는건지 궁금하다. 그러니까 POST 요청으로 설정시에 지정되는 내부 매커니즘이 궁금하다. 왜냐면 앞단에서 POST로 지정을 한다고해도 service에서 delete를 수행해서 리소스가 삭제된다면, 앞단에서 POST로 지정한 의미가 있는건지 궁금하다.
- POST요청시 클라이언트에서 서버로 넘겨주는 데이터의 양은 적을수록 좋은가? 최소한의 정보만 넘겨주고, 서버 내부에서 전부 조회를 해서 필요한 정보를 다 찾는것이 좋을지? 아니면 이미 클라이언트가 가지고 있는 정보는 전부 넘겨주고 조회 데이터를 최소화 하는 것이 좋은지?