REST 갑론을박

REST는

Roy Fielding의 박사 논문에서부터 시작합니다.

그런데, 그 논문은 어찌보면 매우 형이상학적이어서,

우리가 통상 스펙이라고 말하는

특히 프로그래밍 언어 수준의 API도 없습니다.

그러다보니, REST에 대한 해석이 분분한데,

동적인 요소, 예를 들어 서비스들 중에서 어떤 서비스를 지칭할 때 URL로

services/dummy

가 좋을지(혹은 맞을지)

services?name=dummy

가 그런 이슈입니다.

사실 엄밀하게 말하면 ?name=dummy는 URL상의 경로는 아닙니다. 말하자면 부가 정보인 셈이죠. 따라서 특정 리소스의 존재성을 부각시킨다는 차원에서는 services/dummy가 좋아 보입니다. 

한편, 동적인 요소를 파라미터로 처리해오던 것이 그동안의 웹 애플리케이션의 관행이었고, 경로를 분석해서 동적인 요소를 추출하는 것에 대한 API나 설정의 배려가 아직까지 (요청 파라미터 처리에 비해 상대적으로) 부족한 플랫폼에서는 아무래도 현실적으로 services?name=dummy를 선호하게 됩니다.

단적인 실례가 되겠지만,  레일스는 전자를 기본으로 삼는 반면, SOA 책에서는 후자를 선보이고 있습니다.

경로 VS 매개변수의 이슈와 더불어, 또 하나 재밌는 이슈가 있습니다. 바로 명사 VS 동사의 문제입니다.  지난번 강규영님의 멋진 예에서 REST가 리소스의 상태 변경으로 우리가 원하는 동작을 실현한다고 했는데, 상태변경의 표현을 명사로 하느냐 동사로 하느냐 하는 것입니다. 예를 들어

services/dummy?action=investigate

라고 하면 services/dummy라는 리소스에 investigate라는 액션을 취하는 것으로 보이지만, CRUD 입장에서는 (investigate가 기본적으로 리소스를 본다라고 가정하여)

GET services/dummy

로 하면 된다는 것이죠. 특히나 CRUD로 표현이 안되는 동작에서는 더욱 이 논쟁이 뜨겁습니다. 그래서 레일스에서도 ;과 같은 살짝 비표준적인 방식을 썼다가 사파리 브라우저에서의 문제로 _method 파라미터를 쓰고 있습니다.

HTTP 메소드가 확장적으로 쓰이면서 WebDAV 같은 경우에도 HTTP 기본 메소드 이상의 메소드를 정의해 쓰고 있습니다만, 만약 애플리케이션마다 자기나름의 HTTP 메소드를 정해서 쓴다면 어떨까요? 예를 들어

INVESTIGATE services/dummy

이 경우에는 안타까운 것이,  INVESTIGATE라는 메소드는 표준이 아니어서 이 리소스 이외에서는 재활용이 불투명하고, 어떤 리소스가 INVESTIGATE가 가능한지도 알기 힘듭니다.

WADL(Web Application Description Language)과 같은 메타데이터가 이 경우에 도움이 될 수도 있겠네요.

스키마에 WADL에, 점점 웹 서비스처럼 복잡해지는 것을 경계하는 사람들도 있습니다만, 편의성의 측면에서 접근하는 시각도 음미해볼만합니다.