리소스 URL의 진정성

REST에서는 Uniform Identifier가 매우 중요한 개념입니다.
그런데, 이것이 URL로 발현되면서 미묘한 문제가 생깁니다.
예를 들어 스프링노트의 페이지 URL을 보면
http://dev.springnote.com/pages/4434
와 같이 pages/ 뒤로 페이지 ID가 붙습니다.
그런데, 사실 이전 웹 애플리케이션에서는
pages?id=4434
와 같이 짰었죠.
즉, 전에는 /pages와 같은 URL을 리소스(즉 웹의 자원)이라고 생각했다기 보다는,
pages?action=view&id=4434
지극히 RPC스러운 호출 주소(http://..../pages) + 함수(action=view) + 인수(id=4434) 의 구조를 띄고 있었던 것입니다.

그렇다면, 웹에 있는 데이터로서의 리소스는 과연 어떤 URL을 가져야 할까요?
이런 생각을 해봅니다.
pages와 pages?id=3, pages/1의 차이.
pages는 페이지 콜렉션을 의미합니다.
pages?id=3에서 id=3은 매개변수이고, 부가 정보입니다.
즉
pages와 pages?id=3은 본질적으로 같은 리소스를 나타내야 한다는 것입니다.
한편, pages/3 은 pages와는 다른 URL을 가진 리소스입니다.
이렇게 3이라는 숫자를 부가적인 매개변수로 나타내느냐 아니면 경로의 일부로 삼느냐에 따라 리소스에 대한 시각이 달라집니다.

기존 웹 RPC 방식은 URL을 호출의 대상으로 삼고, 무슨 일을 할지와 무엇을 다룰지를 인풋 메시지로 넘겨 그 결과를 아웃풋 메시지로 받았습니다. 반면 REST에서는 URL로 접근할 수 있는 리소스 자체가 컴퓨팅의 대상이고, 그 리소스의 상태와 라이프사이클을 조정하는 일이 바로 웹을 통해 일어날 수 있는 일인 셈입니다.

그렇다면 어떨 때 매개변수 대신 부분 경로를 쓰는 것이 좋을까? 그 정보가 리소스의 타입을 바꾼다면 경로로 들어가는 것이 어떨까요? 예를 들어
pages 는 페이지 콜렉션
page/id 는 페이지 하나
와 같이요.