My Words, Your Memory

물론 언젠가는 이런 저런 블로깅 API들이 IETF의 ATOM Publishing Protocol 로 수렴될 것이라는 생각이다.  ATOM Pub Protocol 은 난해하게 생겨먹은데다 ATOM Syndication Format과 서로 묶여 있기 때문에 당장 쉽게 구현되긴 어렵겠지만, 언젠가는 '국제 표준' 을 향해 가는 게 업계의 생리 아니던가. 그리고 언젠가 그런 날이 온다면 나는 'API를 Open하라' 가 아니라 'ATOM 관련 표준들을 지원/준수하라' 라고 목소리를 높이게 될 것이다.

ATOMPP 가 아직 proposed standard가 되지 않은 상황이지만 그에 상당하는 API는 필요하다. IETF 샌님들의 훌륭한 제안만 기다리면서 목이 빠질 순 없는 노릇이니까. 구글은 Google Data API라는 아주 멋진 API를 제공한다. (정말이지 멋있게 생겼다) 이글루스 역시 GData API 비슷한, 혹은 그와 유사한 형태의 API를 만들 수 있을 것이다. 물론 이글루스가 당장 ATOM syndication format을 채택하진 않을 것이고, 현재 구현되어있는 metaweblog API 를 생각하면 RSS 2.0 spec을 기반으로 하는 형태가 될 것이다.

metaweblog API의 골자는, RSS 2.0 스펙에 정의된 'item' entry를 XML-RPC 의 argument  로 이용한다- 라는 개념이다. API스펙이 극단적으로 짧은 것은 바로 그 때문이다.  item 을 '어디에 어떻게' 할 것이냐를 method 이름 과 arguement 형태로 보내줄 뿐이고, 실제 item에 들어갈 내용들은 RSS spec에 의존한다.  실제로 API 호출의 결과가 반영되어야 하는 target을 지정하는 것은 'blogid' 인자인데, 이는 블로그의 경우, RSS 의 'channel/link' node가 표시하고자 하는 바와 "실질적으로" 동일하다.

따라서, metaweblog API를 블로그에 적용하는 것은, 해당 블로그의 RSS 주소를 key로 삼아 RSS로 표현될 내용들을 읽어오거나, API로 조작하고, 이 조작이 실제로 블로그에 반영되도록 만드는 것- 으로 요약할 수 있다. 이것은 '매우 중요한' 관점상의 변화다. (이게 무슨 말인지 이해하지 못하겠다면 아래 내용은 읽을 필요가 없다. 이 글은 그런 바보들을 위해 씌여지지도 않았다)

이런 관점에서 접근해보면, 블로고스피어의 많은 블로깅 툴들중엔 각 페이지 단위로 덧글 및 트랙백 목록을 RSS 형태로 발행하는 놈늘도 많다. 그렇다면, 이런 경우에 대해서도 metaweblog API 를 적용하는 것도 매우 '당연히 있을 수 있는' 확장이다. 다만 이 경우 item 이 가리키는 것은 블로그 포스팅이 아니라 comment 나 trackback ping 내용이 된다는 것만 다를 뿐이다. (이를 위해 코멘트 및 trackback 들의 RSS 주소에 대한 일정한 규칙을 정의하는 것은 불가피한 일이다. 물론 현재로서도 동적인 데이터 로딩을 위해 iframe 에 읽어올 주소가 일정한 규칙에 의해 부여되고 있으며, 그와 유사한 확장이라고 보면 되겠다)

개별 포스팅에 대한 접근법 뿐 아니라, 현재 RSS로 제공되지 않는 몇 가지 정보들, 즉 '내 블로그에 달린 덧글 전체' 및 '내 블로그에 달린 코멘트 전체' 에 대한 정보들 역시 해당 정보들을 RSS로 제공하는 것과, 제공된 RSS 채널에 대해 metaweblog API를 적용하는 정도로도 문제를 많이 단순화시킬 수 있다.

예를 들어 http://lunaris.egloos.com/comments/index.xml 을 통해 이 블로그에 달린 덧글 들의 목록을 가져올 수 있다면 어떨까?  마치 http://lunaris.egloos.com/comments/ 라는 블로그가 존재하고, 거기 존재하는 많은 item 들 (이 경우엔 코멘트들)에 대해 metaWeblog.getPost 호출이나 metaWeblog.deletePost, etaWeblog.getRecentPost를 호출할 수 있다면, 단지 RSS 가 제공될 때 보다 훨씬 강력한 기능들을 구현할 수 있다. 즉, '덧글 관리' 를 remote 에서 구현할 수 있게 되는 것이다.

이글루스에서 API를 제공한다- 면 아마 이런 형태가 되어야 하지 않을까, 라는 생각이다. 기존의 blogging API와 분리된, 전혀 다른 API를 제공하는 것이 아니라, 기존에 제공되던 RSS뿐 아니라 더 많은 정보들에 대해 RSS를 제공하고, 그 RSS를 API로 접근해서 제어한다는 개념이다. 향후 ATOMPP 로의 진입을 고려한다면, 단지 RPC interface를 더 만드는 것이 아니라 일단은 전체적인 체계를 갖추는 것이 중요하기 때문이다. 당장은 metaweblog API를 대상으로 하겠지만 언젠가는 ATOM 으로 확장될 강력하고 유연한 API를, 그 API를 뒷받침할 수 있는 많은 '정보 채널들'을 바란다.

현재 RSS로 제공되고 API로 제어할 수 있는 정보 채널은, "특정 블로그의 포스팅 채널" 뿐이다. 이제 몇 가지 채널들을 더 정의해보자. 아래 정의들에서 '소유자'와 '비소유자' 는 API 호출시에 제공되는 user id 등에 의해 결정될 수 있다. 또, 물론 채널이 있다고 해서 채널이 반드시실제로 RSS로 제공되어야 하는 것은 아니며, 인증이 필요한 정보들은 오직 API 형태로만 접근 가능하도록 할 수 있을 것이다. 호출시 blogid 는 채널의 link URL과 같거나, 상호간의 변환을 위한 다른 API가 제공되어야 한다.

1) 특정 블로그의 comment 채널 - 비소유자인 경우 공개 코멘들만이 제공된다.
2) 특정 블로그의 트랙백 채널 - 소유자인 경우 전체 트랙백 핑들이 제공된다.
3) 특정 포스팅의 comment 채널, 트랙백 채널 - 블로그 전체가 아니라 주어진 포스팅 주소 하나에만 한정된다.
4) 특정 포스팅의 'related posting' 채널 - 현재 글쓰기에 나타나는 '추천글' 목록이 RSS로 제공된다.
5) 마이 밸리 채널, 덧글 단 포스팅 목록 채널, 체크 포스트 채널 - 현재 '툴바' 에 붙어있는 기능들이 API로 제공된다.
6) 이글루 링크 채널 - OPML 형태로 제공되고 있지만, 이를 채널화해서 API로 접근할 수 있게 한다. 이 경우엔 delete 등의 operation도 가능한 것이 좋겠고,  category 관련 operation 도 지원한다면 꽤 유용할 것이다. 
7) 이글루 '역링크' 채널 - 해당 이글루를 '링크하고 있는' 다른 블로그들의 목록이 제공된다.
8) 밸리 메타 채널 - 주제별 트랙백을 구성하고 있는 '주제들' 과, '이주의 테마' 등 트랙백 캠페인들의 목록이 제공된다.
9) 밸리 아이템 채널 - 주제별 트랙백- 으로 모인 개별 주제나, '이주의 테마'에 모인 글들이 RSS형태로 제공된다. 메타 채널은 일종의 '카테고리의 업데이트' 이며 밸리 아이템 채널은 각 카테고리 별로 모인 포스팅들에 대한 채널이다.

너무 많은가? 하지만 이런 채널들을 생각해보면 이글루스의 채널들이 얼마나 빈약한지가 거꾸로 드러난다. 페이지로는 제공되는데 구조화된 정보로는 제공되지 않는 정보들이 너무 많은 것이다. 분발했으면 좋겠다.