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

Question

'모든개발자를 위한 HTTP웹 기본지식' 에서 배운 바로는 URL를 설계할때, 회원조회를 위한 url 이라 치면, "/member/{id}" 같이 PathVariable인 회원id 값을 url에 명시해 두었습니다. 그런데 이번에 쿠키와 세션을 학습하면서 느낀건데, 애초에 그냥 "/member" 로만 해도, 로그인한 세션값으로 회원 정보를 가져와 해당 회원에 맞는 화면을 응답해도 되지 않을까요? 비슷한 또 다른 예시인데, userA가 자신이 주문한 item들을 전체 조회하고자 할때 요청할 url를 "/orders/{memberId}" 로 하여 memberId를 통해 회원객체를 조회하고, 조회한 객체의 주문목록을 화면으로 뿌려주는것보다는, "/orders" 로만 url을 잡고 세션값을 통해 현재 요청을 날린 회원 객체를 받아 주문목록을 화면에 뿌려주는것이 조금 더 url을 간결하게 만들 수 있지 않을까.. 라는 생각이 들었습니다.   결론: url을 "/member/{id}" 으로 잡았던 이유가 아직 세션을 학습하기 이전이라 그런것인가요, 아니면 다른 이점이 있기 때문일까요?

y2gcoder · Answer

안녕하세요, Shin Berg 님. 공식 서포터즈 y2gcoder 입니다. URL 설계와 관련해서 질문해주셨습니다. 그런데 이번에 쿠키와 세션을 학습하면서 느낀건데, 애초에 그냥 "/member" 로만 해도, 로그인한 세션값으로 회원 정보를 가져와 해당 회원에 맞는 화면을 응답해도 되지 않을까요? URL 설계는 약속에 가깝다고 생각합니다. 그런 의미에서 말씀하신 것처럼 /member를 했을 때 로그인한 본인 정보만 불러오겠다고 클라이언트와 약속했다면 상관없다고 생각합니다. 다만, 일반적으로 /members 와 같이 설계했을 때는 보통 member 라는 리소스 전체를 불러오기 위해 설계하는 경우가 많습니다. 해당 방법으로 지정했을 때 만약 로그인한 사용자가 아니라 다른 사용자의 정보를 불러와야 한다는 요구사항이 생기고, 또 관리자 페이지가 생겨 그곳에서 모든 사용자 목록을 불러와야 하는 요구사항이 생긴다면 기존 URL 설계가 발목을 잡을 수 있다고 생각합니다. 아래의 또다른 예시 또한 마찬가지라고 생각합니다. 만약 관리자 페이지에서 사용자와 관계없이 전체 주문목록을 보면서 관리해야 하는 요구사항이 생긴다면, 기존의 URL 설계가 장애물이 될 수 있습니다. 정말 생명주기가 짧을 것 같고 유지보수를 더 이상 하지 않을 것 같은 프로젝트라면 상관없겠으나, 보통은 프로젝트의 요구사항이 어떻게 바뀔지 모르기 때문에 유연한 설계를 하는 것이 좋다고 생각합니다. 감사합니다.