PR_README.md 추가

[gdtknight]

코드 리뷰 중점 요청 사항

정현수

• 아래 코드는 컨트롤러에서 반환을 담당하는 코드입니다.

  return ResponseEntity.ok(ApiResponse.success());

  클라이언트는 아래와 같이 JSON 형태로 응답을 받는데

  status: 204
  
  body
  {
      "status": 204,
      "success": true,
      "response": null,
      "error": null
  }

  여기서 상태 코드를 204로 반환하는 게 올바른지 잘 모르겠습니다.
  예전에 봤던 글에서 상태코드 204를 반환할 때는 body가 존재해서는 안된다 라는 주의사항을 본 것 같은데 200을 반환하도록 리팩터링하는 것이 올바를까요?

• signUpService의 approve 메서드중

  userRepository.save(user);
  signUpRepository.delete(signUp);
  vacationInfoRepository.save(vacationInfo);

  하나의 메서드에서 여러 레포지토리에 접근하여 저장하거나 삭제하는데 이게 올바른 구조인가요?
  멘토님은 어떻게 코드를 작성하셨을지 궁금합니다.

양수현

황인영

신용호

• JWT 토큰 발급 및 인증 부분을 어느 정도까지 커스터마이징하는게 좋을지 잘 모르겠습니다 !
• Filter 자체를 직접 구현해버리면 굳이 Security 의존성 추가하지 않아도 원하는 기능을 추가할 수 있을 것 같긴 한데, 그러자면 CSRF 나, XSS 방지 해주는 기능들도 함께 사용할 수 없어지니 해당 부분을 고려해야 할 것 같고
• Security 의존성을 추가해서 사용하자니 기타 AuthenticationManager, AuthenticationProvider, Token 까지 마음만 먹으면 커스터마이징 할 수 있는 부분들이 너무 많이 보여서 고민하다가 일이 너무 커질 것 같다는 생각에 결국 이도 저도 시도하지 못했습니다!

[Jungdahee]

모두들 미니 프로젝트 진행하시느라 고생이 많으셨습니다!

질문주신 부분에 대한 답변을 드리면,

1. 204의 경우 응답 본문이 없는 것이 일반적이기 때문에 리팩토링을 진행하는 게 더 적합해 보입니다.
   body를 제거하고, status와 같은 레벨에 success, error와 같은 키 값을 넣어 null로 반환하면 HTTP 규약에 적합한 응답 형식이 될 것 같습니다.

2. 하나의 메소드에서 여러 개의 레포지토리를 활용하는 부분은 자체적으로 문제가 되지는 않습니다. 다만, 이들은 모두 하나의 트랜잭션으로 관리되어야 하고, commit과 rollback에 대한 규칙이 명확하게 부여되어 있어야 하겠죠? 데이터의 수정 및 등록이 일부만 되거나, 수행 중 오류가 있을 때 데이터의 이상이 생기지 않는 방어 장치를 넣는다면 위 구조도 크게 문제는 없을 것 같습니다.

3. 인증 방식 질문에 대해서는, 프로젝트 요구 사항이나 제약 사항에 따라 어떻게 구조를 가져갈지가 달라지게 되는데, 직접 구현하는 방식의 문제는 말씀하신 것처럼 보안적인 요소를 모두 고려해야 하기 때문에 생각해야 할 부분이 많아집니다. 그렇기 때문에 Security를 활용하는 방법을 많이 사용하는 것이기도 하구요! Security를 사용하면서 커스터마이징 할 부분이 많아 고민이셨던 것 같은데, 기본적으로 활용하는 방법을 먼저 작성해 보시고, 이후에 하나씩 커스터마이징을 하는 것이 좋아 보입니다.

모두 고생 많으셨어요 👍 결과물이 잘 나와서 너무 흡족합니다 😄