REST API을 만드는 일이 많아졌다. REST API가 이미 널리 알려진 개념이지만,RESTful하다고 할수 있는 API은 어느정도는 주관적인 요소가 개입되는 것 같다.
이번에 설계를 하면서, Twitter나 Facebook의 API을 참고하긴 했지만, 각각의 스타일의 차이를 알수는 있어도 좋은 디자인 규칙에 대한 정보를 얻기가 힘들었다.
특히 리소스 모델링 부분이 어려운데, REST API Design Rulebook을 참고하여 구성하고 있다.
Resource의 프로토타입을 제시
REST API Design Rulebook에서는 리소스의 원형을 다음과 같이 제시한다.
- 도큐먼트
- 컬렉션
- 스토어
- 컨트롤러
이중에서 가장 흥미로운 리소스 원형은 컨트롤러 리소스와 스토어 리소스이다. 컨트롤러 리소스는 사실 HTTP Method으로는 표현하기 힘든 행동을 리소스로 표현하기 위해 존재한다.
POST /alerts/23456/resend
스토어 리소스는 기본적으로 클라이언트가 관리하는 리소스이다. (다른 3개의 리소스는 서버-사이드 리소스이다) 그리고 새로운 리소스를 만들지 못한다.
예를 들어, 서버에서 관리하는 리소스인 컬렉션 리소스에 어떤 도큐먼트 리소스를 포함(저장)하는 행동을 클라이언트가 스토어 리소스로 할수 있다. (이는 기존에 존재하는 리소스의 관계를 만드는(저장하는) 행동이기 때문에 새로운 리소스를 만든다고 할수 없는 것 같다)
개인적인 짧은 생각으로는 스토어 리소스라는 이름보다는 릴레이션 리소스 같은 이름이 좀더 명확한것이 아닌가 싶다.
이책의 저자는 이런 리소스 디자인을 가지고 Web Resource Modeling Language이라는 프로젝트를 하고 있지만,큰 호응이 있는 것 같지는 않다.
관례적으로 (예상되겠지만) 도규먼트는 단수 명사, 콜렉션은 복수 명사,스토어는 복수 명사,컨트롤러는 동사를 사용한다. http://www.wrml.org/modelingLanguage
이런 리소스의 원형(혹은 규칙)을 가지고 API을 만든다면 좀더 일관성이 있는 REST API을 만들기 좋지 않나 싶다.