Contents
- はじめに
- WikiのWebサービスAPI事情
- Wiki RPC
- 実装状況
- Wiki RPCを使ってみる
- FSWikiとWiki RPCプラグインの設置
- FSWikiの設置
- Wiki RPCプラグインの設置
- Wiki RPCでのアクセス
- ページ名と各ページの情報取得
- ページの投稿とHTML形式での取得
- 今後の可能性
- XML-RPC，Atom API，REST
- WebサービスAPIを介したWikiの活用
- 新しいWikiアーキテクチャ
- 最後に
- このページについて
WikiとWebサービスAPI
はじめに
こんにちは，塚本牧生です．最近は書店に行くと「最新WebサービスAPIエクスプローラ」なるムックが並んでいますが，もうご覧になったでしょうか？
AmazonやGoogle等のWebサービスが相次いでWebサービスAPIを公開したり，blogが共通的な投稿用のWeb APIを用意しているなど，個人が直接恩恵を受けられる機会が増え，WebサービスAPIが身近な存在になってきました．Wikiユーザからもしばしば，「WikiのWebサービスAPIは」という声が挙がりますし，関連ページがはてなブックマークなどでブックマークされているのを見かけます．
今回はWikiのWebサービスAPIについてご紹介します．
WikiのWebサービスAPI事情
WikiのWebサービスAPIと近い関係にあるのは，コンテンツの取得と編集という共通の要求を持つblogのそれでしょう．多くのblogサービスではXML-RPCベースのWebサービスAPIを提供していますが，これと合わせてAtom APIベースのAPIも提供するところが増えてきつつあります．
Wiki RPC
ではWikiはと言うと，まだまだWebサービスAPIを実装したものが少ないというのが実情ですが，その中ではXML-RPCをベースにWiki向けのメソッドを定義したしたWiki RPC Interface（以下Wiki RPCと記述します）という方式が比較的広く使われています．Wiki RPCはJSP WikiというWikiエンジンのホームページで提案され，内容がWiki RPC Interface Version 1(*1)と，Wiki RPC Interface Version 2(*2)にまとめられてきたようです．
ざっと概観すると，Version 1ではWikiの既存ページ名や，そのページの情報，内容を取得するためのメソッドが定義されてきました．Version 2ではさらに，Wikiページを更新するためのメソッドなどが追加されています．また，Version 1ではテキストの引数や返り値がbase64エンコードされていましたが，Version 2では文字コードがUTF-8のテキストのままになっている点が異なります．この他に，Version 2のページを見ると「私たちがたぶん必要とするもの」として，添付ファイルを扱うためのメソッドが検討されていたようです．
各バージョンのメソッドを表1にまとめます．
実装状況
Wiki RPC Interface Version 1は2002年2月24日には現在の形のものが提示(*3)され，その直後に0xDECAFBADというサイトで海外ではポピュラーなtwiki，UseMod，MoinMoinといったWikiエンジン用のWiki RPCの実装例が公開(*4)されています．このサイトで公開されたものには，その後，Version 1のページ上で議論されていたputPageという更新用のメソッドが追加されています．この他，phpWiki，Erfurt WikiなどでWiki RPC実装例を見つけることができます．
Version 2は2003年8月には現在の形の形のものが提示(*5)されており，MoinMoinのWiki RPC実装(*6)はこれに合わせて更新されたようです．また，後述するFree Style Wiki用のWiki RPCプラグインもこれに準拠したものになっています．ただし，Free Style Wikiではページのバージョンの情報を持たないため，getPageVrsionなどのバージョンに関連するメソッドは省略されています．
各メソッドの実装状況を表2にまとめます．
Wiki RPCを使ってみる
WikiのWebサービスAPI状況についてみてきたところで，実際にWebサービスAPIを介してWikiを利用してみましょう．
国内では，竹添氏のPerlによるWikiアプリケーションであるFree Style Wiki（以下FSWikiと記述します）向けに，まかまか氏がWiki RPCプラグインを公開しています．ここではこれを設置し，アクセスしてみることにします．
FSWikiとWiki RPCプラグインの設置
FSWikiもWiki RPCプラグインも，設置は特に難しくありません．以下に簡単に設置と確認方法を記します．また，図1がこの内容にあたりますので，これを参照しながら設置してみてください．
FSWikiの設置
FSWikiのサイトは http://fswiki.poi.jp/wiki.cgi ですが，ダウンロードページに書かれている通り，FSWikiの配布ファイルはSourceforge(*7)に置かれています．ここから，zipファイルを取得してください．本稿執筆時点での最新版はwiki3_5_9.zipでした．
FSWikiの設置自体は通常のCGIとそれほど変わりません．zipファイルを展開すると，本体であるwiki.cgiと，config，data，lib，plugin，thema，tmplといったディレクトリが現れます．wiki.cgiは先頭行のPerlのパスを修正し，他のディレクトリと一緒に設置します．この時，既存ディレクトリの他にattach，backup，pdf，tempという空のディレクトリを作成しておきます．また，CGIファイルには実行権限を，各ディレクトリには読書き権限を与えておきます．
設置が済んだら，wiki.cgiのURLにアクセスしてください．FSWikiのFrontPageが表示されれば設置完了です．
Wiki RPCプラグインの設置
Wiki RPCプラグインは，まかまか氏のXML for Wikiというページ(*8)で配布されています．ここから，tar+gzファイルを取得してください．本稿執筆時点での最新版はwiki_xmlrpc-204.tar.gzでした．
取得したtar+gzファイルを展開すると，wikigate.cgi，wiki_xmlrpc.cgiという二つのCGIファイルと，libディレクトリが現れます．CGIファイルは先頭行のPerlのパスを修正し，他のディレクトリと一緒に，FSWikiの設置ディレクトリに一緒に設置します．この時，CGIファイルには実行権限を与えておきます．
設置が済んだら，wiki_xmlrpc.cgiのURLにアクセスしてください．リクエスト内容を送っていないので何も表示されないのですが，少なくともエラーにならなければ設置完了です．
Wiki RPCでのアクセス
いよいよWiki RPCを利用して設置したFSWikiにアクセスしてみましょう．ここでは，PerlのXMLRPC::Liteモジュールを使うことにします．このモジュールは，SOAP::Liteモジュールをインストールすると利用可能になります．
ページ名と各ページの情報取得
まずは小手調べ．図2は今あるページ名を取得し，その後，各ページの情報を取得するためのスクリプトと，実行結果です．
スクリプトを見てもらうと分かるとおり，XMLRPC::Liteモジュールを使うと，接続先の指定，メソッドの呼び出し，結果の取り出しを書き連ねるだけで一連のアクセスと結果解析を完了できます．ページ名を取得するgetAllPagesメソッドの返り値は配列なので，解析結果は配列リファレンスで返されます．ページ情報を取得するgetPageInfoでは，ページ名を単純に引数で与えており，返り値は構造体なので，解析結果は連想配列リファレンスで返されています．リクエストや結果について，XMLを意識する必要は全くありません．
実行結果を見ると，設置時に自動的に用意されるFrontPage，Help等の各ページの情報が一通り取得できているようです．
ページの投稿とHTML形式での取得
ページ名や概要を取得するだけであれば，RSSを取得し解析しているのと大差はありません．次はページの内容を投稿し，投稿したページをHTML形式で取得します．図3がこのためのスクリプトと，実行結果です．
スクリプトはページ名やその情報の取得とそれほど変わってはいません．ページを投稿するputPageでは，引数にページ名とWiki記法のテキストを与えています．ちょっと違うのは，この時，文字コードをUTF8に変更している点ぐらいでしょう．この結果はintで，成功したので1が返ってきています．次にページの内容をHTML形式で取得するgetPageHTMLを実行しています．結果を見ると，Wiki記法で投稿したページが，ちゃんとHTMLに変換されて返ってきているのが分かります．
図4は，投稿したページにWebブラウザからアクセスしたところです．当然ですが，getPageHTMLの結果から想像される通りの表示になっています．
今後の可能性
ここまで，Wiki RPCを中心にWikiのWebサービスAPI状況をご紹介してきました．しかし，前述の通りまだ普及しているというには遠く，WebサービスAPIの方式も利用方法もデファクトスタンダードがあるとは言い難い状況です．
もちろん逆に言えば，これからWikiのWebサービスAPIがどんどん面白くなっていく可能性は十分にあります．考えてみればWiki RPC Interface Version 2は2003年8月，WebサービスAPIが十分にホットな話題になる前で，Wikiでは議論が止まっているということもできそうです．筆者の予想と期待まじりですが，今後の可能性を示しておきましょう．
XML-RPC，Atom API，REST
冒頭に触れた「最新WebサービスAPIエクスプローラ」や，本誌1月号で組まれたAtom特集では，XML-RPCに続くWebサービスAPIとしてAtom Publishing Protocol，通称Atom APIを解説しています．両記事を読んだ感想ですが，コンテンツの取得と投稿を強く念頭に置いた方式やAtom Autodiscovery等の仕組みはWikiとの相性が良さそうです．
海外では「An Atom-Powered Wiki」(*9)という記事でAtom APIを介したWik利用の解説と，PikiPikiへの実装例が示されています．これを受けてKwikiにはAtom FeedとAtom APIを実装するAtomプラグイン(*10)が公開されています．また，JSP Wikiの開発者であるJanne Jalkanen氏自身が，Wiki RPC Interface Version 2のページにあるディスカッション部で「これは実現済み？それともまだ開発中かアイディア段階？」との問いに「Just an Idea」と答えていたり，また「将来の作業としてはAtom APIを採用すべきだと考えている」と書いているのはちょっと気になります．JSP Wikiの動き次第で，現在のKwikiの影響力とあいまって一気にAtom APIへの流れが加速するかもしれません．
ところで，AtomではAtomデータ自体をRESTでもSOAPでも送受信できるのですが，ハックな考え方をすれば「Wikiページに対してGET，POST，PUT，DELETEを投げるRESTなら，直接Wiki記法のテキストをRESTで投げたらどうだろう」という考え方もありえるでしょう．実際にこうした実装として，9月にはごろう氏がREST Wiki(*11)を公開されました．連載第2回でご紹介したようなシンプルなWikiであれば，この方式が十分に動作することが分かります．
正直に言って，どの方式が生き残っていくのか，あるいはどういった形で共存していくのかはまだ見えません．また，一言でWikiといっても，例えばMediaWikiのようにあるページ名にページ本文とノート（Wikipediaでは「裏ページ」と説明されています）がある場合，どう扱えば良いのかなど，Wikiの考え方が多様化してくるとそれに応じてまた難しい問題もでて来そうです．
- *9 : http://www.xml.com/pub/a/2004/04/14/atomwiki.html
- *10 : http://search.cpan.org/dist/Kwiki-Atom/
- *11 : http://rails2u.com:8008/
WebサービスAPIを介したWikiの活用
WikiでWebサービスAPIが普及すれば，今とはもっと違った利用形態，そして利用方法が広まるはずです．
最初に考えられるのは，ecto(*12)やBlogWrite(*13)のようなデスクトップクライアントでの編集でしょう．XML-RPCではBlogで使われるメソッドとWiki RPCのメソッドが一致しないのですが，Atom APIであれば既に使えるのかもしれません．こうしたツールで編集もファイル添付も簡単に行えるようになれば，ファイルアップローダやblog以上に情報共有ツールとして気軽に，便利に利用されていきそうです．
また，Blogを横断した検索やBlogRollingのように，複数のWikiを横断するメタWikiアプリケーションという可能性も出て来ます．InterWikiなど，Wiki間をシームレスにつなげたいという要求は昔からあり，WebサービスAPIはそれを飛躍的に推し進めるかもしれません．Wikiに限らず，他のツールとも連携できますから，ワークフローツールの一部として使うような形態もできてくるかもしれません．
例えば執筆でWikiを使っているという話を良く聞くようになりました．これがWikiで共同執筆された原稿が，編集部のBlogにPOSTされ，編集者や監修者が「既読（＝チェック済み）」マークをつけると自動的にデザイナにメール送信，デザイナが返信した組版データとPDFがBlogに添付され，そこから組版データが印刷所に流れ，PDFがWikiにPOSTされる．こんな仕組みもAPIが整って期待まであればすぐに実現できそうです．あるいは企画部のblogにアイディアがどんどんエントリされ，モノになると思われたものはWikiにPOSTされてディスカッションとブラッシュアップが行われ，PDF化されて稟議担当者にメールされるなど，活用の幅はアイディアの数だけ広がります．
昨年の話になりますが，Kwikiを含む商用サービスを提供するSocialtextのblogにAtom Wiki and the Writeable Webというエントリ(*14)が掲載されました．このエントリでは，「KwikiからMovable Typeに投稿するための作業をした」「ectoのようなデスクトップクライアントでのWikiへの投稿にまず興奮した」など，すでにベーシックなAtom APIの効用を垣間見せています．
- *12 : http://ecto.kung-foo.tv/index.php
- *13 : http://witha.jp/BlogWrite/
- *14 : http://www.socialtext.com/weblog/040914wikiatom.html
新しいWikiアーキテクチャ
Wikiそのものの活用と同時に，筆者が夢想しているのはより柔軟なWikiシステムのアーキテクチャが実現できないかです．この話をすれば夢物語，大風呂敷，非現実的と言われるかも知れません．でもWikiアプリケーションを，テキストとHTMLの変換を受け持つWikiエンジンと，データを保持するWikiストレージに分けて，その間をAPIで結べば，個人でも設置できる柔軟な分散環境にならないかと思っています．
図4がこの形態になります．この形態では，WikiエンジンとWikiストレージは開発言語や動作環境，設置サーバが別でも良くなります．WikiエンジンとWikiストレージが1対1でなくても良く，重い変換処理を行うWikiエンジンは複数設置し，Wikiストレージは一箇所ということもできます．意義があるか微妙ですが，WalWikiとHikiとPukiWikiとFSWikiのWikiエンジンサーバが，同じWikiストレージにアクセスすることもできます．逆に，Wikiストレージも入り口が一箇所であれば，実際にデータを持つバックエンドを分散することができるかも知れません．
同時に，WikiのプラグインもWikiエンジンやWikiストレージから切り離すことができます．例えば，Wikiトラックバックプラグインというものがあるとして，これがAPIを介して直接Wikiストレージ上のトラックバック先のページデータを更新するようにできていれば，どのWikiでも使えることになります．ここで採用されているのがAtom APIのように共通的なAPIであれば，同じ理屈でblogのエンジンもストレージと分け，Wikiとblogが同じストレージを見るようなこともできそうです．例えば，Wikiで新規作成されたページがblogの形で表示されると便利かも知れません．
図5が，夢物語の集大成です．各所でAPIを介した通信が行われ，当然それだけのオーバーヘッドがあります．でも，デメリットははっきりしているのだけど，それでも可能性を感じないでしょうか．
最後に
今回はWikiのWebサービスAPIという面について，現在の主流な実装であるWiki RPCを中心にご紹介しました．また，今後の動きとしてAtom APIやRESTなどにも触れました．汗顔の極みではありますが，さらに筆者の夢物語も交えています．
WikiのWebサービスAPIは，まだ当たり前のものにもなっていませんし，デファクトスタンダードもなく，活用されているとも言えない状況です．でも，それを検討する動きはありますし，筆者はその先に大きな可能性を感じています．この可能性を，お読みくださった皆様にも共有していただければ幸いです．
このページについて
| 作成者 | 塚本 牧生 |
| 内容 | Software Design 2005年12月分原稿 |
