리소스 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 는 페이지 하나
와 같이요.

RPC vs REST의 좋은 비유

지난 스터디에서 강규영님이 RPC와 REST를 비교하는 좋은 비유를 들어 주셨습니다.

사용자가 어떤 서비스를 쓰기 위해 인증하는 과정을 겪는데, 그때 기능적으로

로그인
로그아웃

이라고 본다면, 상태적으로는

사용자 세션이 있는가 없는가

로 대응된다는 것입니다.

좀 더 구체적으로 형상화해보면, 웹 서비스에서는

http://localhost:8080/AuthService 엔드포인트에
... 또는 ...

과 같이 메시지를 날리는 것과 REST에서

http://localhost:8080/session 리소스에
POST로 생성, DELETE로 제거를 하는 것이 같다는 뜻입니다.

즉 “행위”가 “상태의 변이”로 1대 1 투영되는 셈입니다.

SOA Using Java Web Services 번역을 시작하며

안녕하세요?
이 블로그는 SOA Using Java Web Services의 한국어 번역(출판사는 위키북스)을 맡은 팀의 공식 블로그입니다.

앞으로 책에 관련된 소식이나 번역 팀의 스터디로부터 얻어 함께 하고 싶은 생각들을 쓸 예정입니다.

번역서의 출간은 2007년 4사분기로 희망하고 있습니다 ^^

여러분들의 많은 관심과 참여(덧글을 통한 질문이나 의견) 바랍니다.
고맙습니다.