이전 포스팅에서 REST API 설계 원칙을 공부하고 실제 프로젝트의 URI를 리팩토링하는 과정에서,
가장 고민이 많았던 부분은 회원 관련 API였다.
프로젝트 초기에 회원 관련 API는 /auth, /members, /profile 세 가지 리소스로 나누어 사용하고 있었다.
- /auth → 회원/비회원 여부를 구분하는 용도
- /members → 회원 엔터티에 대한 CRUD와 동시에 로그인/로그아웃까지 담당
- /profile → 회원 활동 데이터 조회
그러나 REST API 설계 원칙을 다시 살펴보니 현재 구조는 문제가 있었다.
- /members에서 인증(로그인/로그아웃) 기능까지 담당하고 있었음
- /profile은 사실상 회원 엔터티(/members/{memberId})의 역할을 중복하고 있었음
- /auth는 단순히 회원/비회원을 구분하는 수준에 그치고 있었음
즉, 각 리소스의 역할이 뒤섞여 있어서, 실제 개발 과정에서 API의 역할을 직관적으로 파악하기 어려웠다.
결국 코드를 직접 확인하거나 프론트엔드에서 호출되는 API를 추적해야 무슨 역할을 하는지 알 수 있었다.
리팩토링 방향
-
/members
회원 엔터티 자체를 다루는 리소스로 제한.
→ 회원가입(등록) 및 공개 가능한 회원 정보 조회 정도로만 사용. -
/auth
인증(Authentication) 전용 리소스.
→ 로그인, 로그아웃, 토큰 갱신 등 인증/인가와 직접 관련된 작업만 담당. -
/profile → /me
/profile은 사실상 /members/{memberId}와 동일한 의미로 쓰이고 있었음.
하지만 REST 관례상 현재 로그인한 사용자 자신을 표현하는 /me가 더 직관적이므로 이를 대체 리소스로 사용.
→ 내 정보 조회, 내 활동(여행 일정 등) 조회/수정에 활용.
결론
/members — 회원 엔터티 관리
회원가입과 같은 비회원 등록 작업이나, 회원 목록·프로필 조회 등 공개 정보 제공이 필요한 상황에서 사용된다.
POST /members # 회원가입
GET /members # 회원 목록 조회 (예: 랭킹, 검색 결과)
GET /members/{memberId} # 특정 회원의 공개 프로필 조회/me — 현재 로그인한 사용자
항상 현재 로그인한 나 자신을 의미하므로 별도의 식별자를 붙이지 않는다.
내 계정 정보와 내가 만든 활동 데이터를 조회·수정할 수 있다.
- 회원 자기 정보
GET /me # 내 계정 정보
PATCH /me/nickname # 닉네임 수정
PATCH /me/password # 비밀번호 수정
DELETE /me # 회원 탈퇴
- 회원 활동 데이터
GET /me/travel-plans # 내가 만든 여행 일정 목록
GET /me/travel-plans/42 # 내 여행 일정 단일 조회/auth — 인증과 인가
/auth는 말 그대로 로그인, 로그아웃, 토큰 갱신 등 인증 관련 작업만을 담당한다.
회원 데이터나 프로필은 여기서 다루지 않는다.
- 로컬 로그인
POST /auth/sign-in
POST /auth/sign-out
POST /auth/refresh # JWT 재발급
- 로그인 여부 확인
GET /auth/me # 현재 로그인 상태 확인