인프런 커뮤니티 질문&답변

Shin Berg님의 프로필 이미지
Shin Berg

작성한 질문수

스프링 MVC 2편 - 백엔드 웹 개발 활용 기술

ArgumentResolver 활용

세션을 사용할 수 있다면, URL를 설계할때, /member/{id} 와 같이 PathVariable를 가져갈 필요가 있을까요?

해결된 질문

작성

·

551

·

수정됨

0

'모든개발자를 위한 HTTP웹 기본지식' 에서 배운 바로는 URL를 설계할때, 회원조회를 위한 url 이라 치면, "/member/{id}" 같이 PathVariable인 회원id 값을 url에 명시해 두었습니다.

그런데 이번에 쿠키와 세션을 학습하면서 느낀건데, 애초에 그냥 "/member" 로만 해도, 로그인한 세션값으로 회원 정보를 가져와 해당 회원에 맞는 화면을 응답해도 되지 않을까요?

비슷한 또 다른 예시인데,

userA가 자신이 주문한 item들을 전체 조회하고자 할때 요청할 url를

"/orders/{memberId}" 로 하여 memberId를 통해 회원객체를 조회하고, 조회한 객체의 주문목록을 화면으로 뿌려주는것보다는,

"/orders" 로만 url을 잡고 세션값을 통해 현재 요청을 날린 회원 객체를 받아 주문목록을 화면에 뿌려주는것이 조금 더 url을 간결하게 만들 수 있지 않을까.. 라는 생각이 들었습니다.

 

결론:

url을 "/member/{id}" 으로 잡았던 이유가 아직 세션을 학습하기 이전이라 그런것인가요, 아니면 다른 이점이 있기 때문일까요?

답변 1

0

안녕하세요, Shin Berg 님. 공식 서포터즈 y2gcoder 입니다.

URL 설계와 관련해서 질문해주셨습니다.

그런데 이번에 쿠키와 세션을 학습하면서 느낀건데, 애초에 그냥 "/member" 로만 해도, 로그인한 세션값으로 회원 정보를 가져와 해당 회원에 맞는 화면을 응답해도 되지 않을까요?

URL 설계는 약속에 가깝다고 생각합니다. 그런 의미에서 말씀하신 것처럼 /member를 했을 때 로그인한 본인 정보만 불러오겠다고 클라이언트와 약속했다면 상관없다고 생각합니다. 다만, 일반적으로 /members 와 같이 설계했을 때는 보통 member 라는 리소스 전체를 불러오기 위해 설계하는 경우가 많습니다. 해당 방법으로 지정했을 때 만약 로그인한 사용자가 아니라 다른 사용자의 정보를 불러와야 한다는 요구사항이 생기고, 또 관리자 페이지가 생겨 그곳에서 모든 사용자 목록을 불러와야 하는 요구사항이 생긴다면 기존 URL 설계가 발목을 잡을 수 있다고 생각합니다.

아래의 또다른 예시 또한 마찬가지라고 생각합니다. 만약 관리자 페이지에서 사용자와 관계없이 전체 주문목록을 보면서 관리해야 하는 요구사항이 생긴다면, 기존의 URL 설계가 장애물이 될 수 있습니다. 정말 생명주기가 짧을 것 같고 유지보수를 더 이상 하지 않을 것 같은 프로젝트라면 상관없겠으나, 보통은 프로젝트의 요구사항이 어떻게 바뀔지 모르기 때문에 유연한 설계를 하는 것이 좋다고 생각합니다.



감사합니다.

Shin Berg님의 프로필 이미지
Shin Berg
질문자

아아..그렇군요 답변 감사합니다!

파이팅입니다!

Shin Berg님의 프로필 이미지
Shin Berg

작성한 질문수

질문하기