VLAAH API가 나아갈 길
VLAAH API 1.0을 릴리즈하고 나서 VLAAH API에 대해 여러가지 고민을 했다. 어떻게 하면 VLAAH API를 매력적으로 만들 수 있을 것인가? VLAAH API를 쓰고 싶도록 만들어야 한다. 내 생각에 API를 쓰게 만드는 요인은 크게 세 가지이다.
- 리소스 아웃소싱(resource outsourcing)—그러니까 자원에 대한 부담을 외부로 돌리기 위해서. 웹 서비스의 API는 이 관점에서 대부분 읽기 위해서든 쓰기 위해서든 스토리지의 역할을 해낸다. Flickr API의 주요 기능들 따위가 여기에 속한다.
- 복잡하고 귀찮은 계산(calculation)의 추상화. Google 검색 API 같은 것들이 여기에 속한다.
- 편하고 마음에 드는 인터페이스. 기능이 좀 부족해도 쓰기 편한 인터페이스면 개발자로 하여금 쓰고 싶게 만든다.
VLAAH API는 기본적으로 1에 해당하는 것을 제공한다고(해왔다고) 생각한다. 3에 해당하는 것은 좀 부족할 수도 있겠다는 생각이 최근 들었다. HTTP에 대해 어느 정도 이해하고 내용 협상(content negotiation) 같은 것에 대해 알아야 하기 때문이다. 그리고 단순히 브라우저에서 응답을 확인해보기 힘들다는 지적도 있었다.1 나는 이 부분에 대해서는 추상화된 각 언어별 클라이언트 라이브러리를 제공하는 것으로 어느정도 해결했다고 생각한다.2 게다가 Atom 피드에 API의 주요 기능을 이미 집어넣었기 때문에, 그걸로도 충족되는 부분이다.3
VLAAH API가 부족한 부분은 현재 2에 해당하는 것이다. 이를테면 VLAAH API는 사용자 간의 취향 집합이 어느 정도의 유사도를 가지고 있는지라거나, 두 주제가 어느 정도의 관련성을 가지고 있는지, 아직 투표하지 않은 주제에 대해 사용자가 어느 정도의 선호도를 가질지 예측해주는 식의 기능을 전혀 갖고 있지 않다. 그러니까 현재의 VLAAH API는 사용해봤자 저런 기능들은 클라이언트 코드에서 직접 구현해줘야 한다는 뜻이다. 구현하려고 해도 HTTP를 통해 통신하는 RPC이므로 대량의 데이터를 가지고 분석하기도 힘들다.
그래서 현재 VLAAH 마일스톤의 큰 두 줄기 중 하나는 바로 이러한 계산 추상화를 구현해서 API로 노출시키는 것이다. 빠르면 올해 상반기 내에 오픈할 수 있을 것 같다. 아마 그쯤 되면 버전도 2.0이 되지 않을까 생각한다.
-
그래서
curl같은 유틸리티를 써야 한다. 예를 들면 다음과 같이.curl -H"Accept: text/xml" \ -H"User-Agent: AppName/1.0 (appkey/appkey-goes-here)" \ http://vlaah.com/~dahlia -
맨 처음에는 내가 VLAAH-Ruby를 작성했지만 지금은 업데이트가 잘 안되고 있고, 강성훈 씨가 작성한 vlaah-python을 메인으로 생각하고 있다. 둘 다 처음 작성했을 때는 VLAAH API 0.9 스펙만 구현하고 있었지만, VLAAH API 1.0을 만드는 과정에서 내가 직접 코드를 기여하여 vlaah-python이 현재로서는 유일한 VLAAH API 1.0을 구현하는 클라이언트 라이브러리가 되어있다. 그 외에도 Objective-C와 Go로 작성된 것도 있으니, 자세한 것은 클라이언트 라이브러리 목록을 참고. ↩
-
http://vlaah.com/~dahlia/comments/atom.xml로 접속해보시라.
http://vlaah.com/네임스페이스로 부가적인 정보들을 함께 제공하고 있다. 당연히 이 URL에 대해서는 애플리케이션 키 따위를 요구하지 않는다. ↩