Closed chock-cho closed 1 month ago
아아 넵 그럼 로그인(/api/login
) 로직 자체에서 그냥 jwt 토큰 값을 리턴하는 걸까요? 🥲
제가 짠 기존의 회원가입(/api/signup
) api의 로직에서는 요청 헤더값으로 oauth 토큰이 오고, 회원가입 성공 시 응답으로 jwt Token을 발급해준다고 생각했습니다.
그렇다면 현재 로직은 로그인 (/api/login
) api 에서 oauth 토큰 요청 ➡️ jwt 토큰 응답으로 권한 얻은 후에, 회원가입 (/api/signup
) api에서는 요청 헤더값으로 jwt 토큰 넘어옴 ➡️ 정보 입력 후 db 반영한다고 보면 될지 여쭙습니다.
/my/addInfo
) 관련업데이트가 필요한 key-value쌍(필드값)에 대해서만 업데이트를 하는 식으로 짜면 될까요?
기존 코드는 dto에서 추가 정보에 필요한 필드값을 모두 포함하여 전송하도록 구현해놓았는데, 이 경우 클라이언트 측에서 업데이트가 불필요한 필드값까지 입력해야한다는 번거로움이 있을 것 같습니다.
예를 들어, dto에서 occupation 필드만 전달되었다면, 직업 필드만 업데이트되고 나머지 필드는 기존 값을 유지하는 로직으로 짜도록 하면 될지 여쭙습니다.
회원가입 로직 관련
아아 넵 그럼 로그인(
/api/login
) 로직 자체에서 그냥 jwt 토큰 값을 리턴하는 걸까요? 🥲제가 짠 기존의 회원가입(
/api/signup
) api의 로직에서는 요청 헤더값으로 oauth 토큰이 오고, 회원가입 성공 시 응답으로 jwt Token을 발급해준다고 생각했습니다.그렇다면 현재 로직은 로그인 (
/api/login
) api 에서 oauth 토큰 요청 ➡️ jwt 토큰 응답으로 권한 얻은 후에, 회원가입 (/api/signup
) api에서는 요청 헤더값으로 jwt 토큰 넘어옴 ➡️ 정보 입력 후 db 반영한다고 보면 될지 여쭙습니다.추가 정보 수정(
/my/addInfo
) 관련업데이트가 필요한 key-value쌍(필드값)에 대해서만 업데이트를 하는 식으로 짜면 될까요?
기존 코드는 dto에서 추가 정보에 필요한 필드값을 모두 포함하여 전송하도록 구현해놓았는데, 이 경우 클라이언트 측에서 업데이트가 불필요한 필드값까지 입력해야한다는 번거로움이 있을 것 같습니다.
예를 들어, dto에서 occupation 필드만 전달되었다면, 직업 필드만 업데이트되고 나머지 필드는 기존 값을 유지하는 로직으로 짜도록 하면 될지 여쭙습니다.
회원가입 로직 관련 -> 정확합니다 추가 정보 수정(/my/addInfo) 관련 -> 네, 전달된 필드만 업데이트 되도록 구현하시면 됩니다! 회원가입 api에서도 동일합니다
📌 관련 이슈
39
✨ PR 내용
⚠️ 추가 발견된 버그
📚 레퍼런스 혹은 궁금한 사항들
📸 스크린샷(선택)
회원가입 -
POST /oauth2/signup
추가 정보 수정 -
PATCH /my/addInfo