REST API 설계에 대한 고민

내가 성장하는 것이 다른 사람에게 좋은 영향을 줄 수 있다.

그래서 나는 잘 되야만 한다.

나는 진짜 ㄹㅇ 조만간 잘 될 사람이다.

어차피 잘 될 것이고, 지금도 잘 된 사람이다..

요즘 폭풍성장 중이다.

어쨋든간에 나는 어잘될사다.

---

❗Notification❗두서 없음 주의❗

REST API 설계에 대한 고민을 했다.
어떤 부분인가...

현재 2023년 6월에 진행하고 있는 프로젝트의 회원이 가입하는 로직은 다음과 같다.

// 소셜로그인을 한다.
// 소셜로그인을 통한 사용자 정보 중 이메일 정보를 가져온다.
    // 이메일이 DB에 있으면, 이미 가입된 사람이고,
    // DB에 없다면, 새로 가입한 사람이다.
// 새로 가입한 사람이 서비스를 이용할 때 닉네임을 가지고 활동하게 되므로, 닉네임을 설정해줘야 활동이 가능하다.
// 고로 닉네임을 설정해준다.

이런 로직으로 회원가입이 진행된다.

그런데 멤버 정보를 수정하긴하는데,

일단 멤버가 생성된 상태이므로, 닉네임을 넣어주려면, Patch메서드를 사용해야 할 것 같다.(당연하게도..)

그런데 가입시 필요한 데이터는 닉네임만 설정하면 된다.

그럼 뭐가 문제냐..?

일단은 결론을 내고 고민을 풀어보겠다.

일단 결론부터 말하면,

설계한 REST API를 통해서 데이터 처리가 적절히 잘 되도록 하면 된다.

참 당연한 말이라고 생각하는데,,,왜 이렇게 말을 하게 되었을까..??

일단 나는 백엔드를 맡았고, REST API를 설계할 때, 뭔가 UI 적인 느낌에서 REST API에 대한 설계를 고민했던거 같다.

먼저 컨트롤러 부분 부터 말해보면,

일단 회원가입 로직상
OAuth2 소셜 로그인을 통해서 사용자에게 JWT가 발급되면 인증된 사용자로서 가입을 진행하게 되고,
프론트와 얘기된 것은 신규회원에게 모달창을 띄워서 닉네임을 설정하도록 한 것이다.

그럼 사용자가 사용할 닉네임을 입력하고 전송을 하게되면 닉네임 정보가 DB에 들어가게 될 것이다.
그런데 닉네임 정보를 입력하는 과정이 사실 회원가입 로직의 일부인데,,,
닉네임을 수정하려면, HTTP 메서드 중 Patch 메서드를 사용해야할 것 같다.

그런데, Patch 메서드를 이용하면서 API는 /member/create로 사용하자니...
참 고민이다..

그래서 전 프로젝트의 MemberController를 보게 되었다.
이 친구가 참 잘했다..

그런데 각 HTTP 메서드마다 Mapping해준 URI가 없다,,,

이 부분을 보고 "설계한 REST API를 통해서 데이터 처리가 적절히 잘 되도록 하면 된다."고 말하게 된 것이다.

사실 Controller 쪽에 Patch 메서드를 두번 쓰면서도 "회원정보를 수정하는 메서드, 가입을 위한 메서드를 따로 나눠야될까?"라고 생각했었다.

동시에 "DTO도 따로 나눠야하나..?" 라고 생각하게 되었다.

===

잠시 DTO에 대한 얘기도 해보자면...

DTO를 사용해서 수정할 데이터를 넘기려고 하는데,
"가입하는데 필요한 닉네임 정보를 전달하는 객체(DTO)와 사용자 정보를 수정하기 위해 필요한 데이터를 전달하는 객체(역시 DTO)를 따로 구분해야 할까...?"
라고 의심을 했다.

사실, 그냥 구분하지 않고, 하나의 Patch 메서드를 사용해서
프론트 쪽에 "닉네임은 한번 설정되면 다음에 변경되지 못 하도록 처리해주세요" 라고 하면 될 것이다.
~그 처리 이름이 생각이 안 난다.. 누가 알면 댓글에 알려주세요.. 그 입력된 상태로 남아있는데 흑백으로 까맣게 되서 클릭 자체가 안 들어가도록 하는 그 뭐시기 있는데 여튼 그거요..~~

동시에 백엔드에서 '인증된 사용자의 닉네임이 중간에 달라졌는지 아닌지'에 대한 검증도 같이 해주면 될 터이다.

===

여튼 다시 얘기로 돌아가서 REST API에 대한 지금 내 생각을 말하자면,

굳이 URI를 덕지덕지 붙일 필요가 없다.

그리고 URI를 굳이 더 붙인 REST API의 느낌은 내가 뭔가 UI 적인 측면에서 생각했던 부분도 있는 것 같다...

왜냐하면 그럴 것이 이번 프로젝트에서 배포가 잘 되었는지 확인하는 절차에서 SSR 방식으로 index.html이 굳이 필요없음 에도 불구하고, 따로 만들어서 확인했던 부분이 있기 때문이다.
그리고 이거 때문에 삽질을 많이했다..

다시 결론을 내보자면, Member에 대한 REST API를 설계하는데, 각 HTTP 메서드의 매핑에 URI를 따로 추가할 필요는 없다.

그냥 "/member" 로 Contoller의 RequestMapping을 설정했는데 해당 매핑주소에 HTTP 메서드만 다르게 적용해서 데이터를 잘 처리되게 하면 된다.

따라서 닉네임 설정을 하는데 있어서도, Patch 메서드 한 번만 사용하되,

닉네임이 한번 설정되었으면, 다시 설정되지 않도록 중간에 검증 로직을 넣어서
재설정이 안 된다고 예외 처리를 해줄 수도 있고(물론 프론트에서 사전에 해주겠지만, 백에서도 검증을 해야하기 때문) ,

그리고 DB에서 사용자 정보를 불러와서 NickName이 null인지 아닌지를 따져서 프론트에 "이 사용자는 닉네임이 없다"라는 정보를 줄 수도 있고,

어쨋든 하나의 Patch메서드에 매핑된 메서드, 하나의 Patch를 위한 DTO를 사용해서 서비스 로직에서 얼마든지 다양한 방식으로 검증이 가능하다.

결론은

1. 일단 현 프로젝트의 규모에선 Patch를 위한 메서드는 DTO든 메서드든 하나만 있어도 충분하다.
2. REST API에 맞게 데이터처리만 잘 해주고 넘겨주면 되고, 굳이 URI를 더 붙일 필요가 없다는 것.

이 두 줄을 결론짓기 위해 두서 없이 혼자 얘기해봤다.

아래는 작성 중인 Controller와 DTO인데...
이...이런 바보 같은 코드를 짜다가 글을 끄적여봤다...
나의 치부를 드러내며 이만 다시 고민을 하러 가본다..