Ogawa::Memoranda

PaginatedFeed公開 - Ogawa::Memorandaの背景と意義を説明するのがこのエントリーの目的です。

Movable Typeを含むブログツールを使っているほとんどの人にとって、RSSやAtomとは、再構築時または閲覧時に勝手にレンダリングされる特定のXML形式で書かれた「ファイル」だ、そのファイルをアグリゲートしてブログリーダやブログ検索などのサービスが提供されるのだ、という認識かもしれません。

物理的な実体としてのフィードは確かにそういう認識であってもよいのですが、フィードはブログの「インタフェース」でもあります。それぞれブログには(各Webページのlink要素によって)フィードURLが関連付けられており、フィードURLは、GETリクエストを受け取るとフィード(=機械的に操作可能なブログのメタ情報)をレスポンスとして返す「Web API」になっています。ブログリーダやブログ検索などはそのAPIを介して収集したフィードをサービスの対象にしているわけです。

そう考えると、ただ最新のN件のエントリーを取り出せるだけでは、Web APIとしてはあまりにもしょぼくね？と思えてくるはずです(思えない？そうですか、それでもいいですが私はしょぼいと思います。もっとリッチなAPIを提供してアプリもそうしたAPIに対応するようになった世界の方に夢を感じます。)。

例えば、Google Blogger (beta)のフィードURLは、GData APIのエンドポイントURLになっていて、GETリクエストによって(Paginationを用いて)全エントリーの内容とメタ情報、エントリーのEditURIを取得できるようになっています。もちろんそれだけでなく、フィードURLやエントリーのEditURIに対して更新操作も可能です。

GData APIなみの機能を実現することは当面無理だとしても、全エントリーとメタ情報を取得できるようにすることは難しくありません。そういうわけで、それを実現したのがPaginatedFeedなのです。

Paginationのナビゲーション用にOpenSearch 1.1 Response elementsを含むようにしたことに関しては若干の議論の余地があるかと思います。もしナビゲーション用のlink要素がなければ、「PaginatedFeedに特定の引数とともにGETリクエストすれば所定のエントリー群の情報が得られることを知っているクライアント」でなければ任意のエントリーの情報を取得することはできません。これに対して、OpenSearchのResponse elementsを含めておけば、OpenSearch用のクライアントが共通のインタフェースでフィードを取り扱える、という利点があります。ついでに言うと、これはGData APIのフィードでも採用している方式でもあります。もちろん、alternativeな方法を採ることもできますが、そうする意味もないでしょう。

さて、もう語ることはあまり残っていません。

PaginatedFeedを活用するには、特定の引数とともにGETリクエストすれば所定のエントリー群の情報が得られることを知っているクライアントかOpenSearchクライアントを用意する必要があります。そうでなければ通常のフィードと変わりありません。

ブログ検索用のクローラーがOpenSearchに対応していれば、いずれは全文検索してくれるようになる(かも)、と信じて枕を高くして寝ましょう。

そうそう、これはまったくコンテキストが異なりますが、Movable Typeのmt-search.cgiをOpenSearchに対応させるという話なら、Niall Kennedyがずいぶん前に書いているので、そちらに興味がある方は以下を参考にされるとよいでしょう。

OpenSearch standard using Movable Type