AtomPubな何かを作ってみよう その6 〜実装編 Part.05「サービス文書を提供しよう」〜
今回は、サービス文書のお話です。
サービス文書は大事
サービス文書は、"どんなコレクションが存在していて、どんな操作をする事ができる"といった、提供しているサービスの内容が記述されたものです。
汎用のAtomPubクライアントでは、サービス文書を元に処理を行うようなものもあるので、AtomPubのサービスを提供するのであれば、サービス文書をきちんと提供するべきでしょう。
…という事は重々承知していたものの、本シリーズのここまでの記事で作成したリソースは残念ながら全くサービス文書を提供していません。
このままではAtomPubサーバとしてはよろしくないので、サービス文書を提供してみましょう。
サービス文書の欠点
という事でサービス文書の提供を考える訳ですが、実はサービス文書には困った問題があります。
詳細に関しては、たけまるさんが書かれた記事が詳しいので、そちらをご参照下さい。
→たけまる / AtomPub - サービス文書の記述力
今回のシリーズ記事で作成したリソースで考えると、入口としてのサービス文書は次のようなものになるでしょう。
<?xml version="1.0" encoding="utf-8"?> <service xmlns:app="http://www.w3.org/2007/app" language="ja" xmlns="http://www.w3.org/2005/Atom"> <workspace> <atom:title>名付けて.ね〜む</atom:title> <collection href="http://www.stellaqua.com/naduketename/api/meanings"> <atom:title>単語一覧</atom:title> </collection> </workspace> </service>
しかし、意味語リソースは子リースとして、コメントリソースや訳語リソースを持っているので、たけまるさんが指摘されている問題にモロに直面する事になります。
リソースの親子関係の意味から考えると、"意味語リソースの各エントリが、コメントリソースと訳語リソースを持っている"という事をサービス文書として示す事ができれば良さそうです。
たけまるさんの記事の提案に乗っかるならば、次のような感じになるでしょう。
<?xml version="1.0" encoding="utf-8"?> <entry xmlns:app="http://www.w3.org/2007/app" language="ja" xmlns="http://www.w3.org/2005/Atom"> <id>tag:tom@nadukete.name,2008:meanings/1</id> <updated>2009-03-08T00:00:00+09:00</updated> <author> <name>TOM</name> </author> <title>作成する</title> <content type="text"></content> <link href="http://www.stellaqua.com/naduketename/api/meanings/%E4%BD%9C%E6%88%90%E3%81%99%E3%82%8B" rel="edit"/> <app:service> <app:workspace> <title>作成する</title> <app:collection href="http://www.stellaqua.com/naduketename/api/meanings/%E4%BD%9C%E6%88%90%E3%81%99%E3%82%8B/comments"> <title>「作成する」のコメント一覧</title> </app:collection> <app:collection href="http://www.stellaqua.com/naduketename/api/meanings/%E4%BD%9C%E6%88%90%E3%81%99%E3%82%8B/namedwords"> <title>「作成する」の訳語候補一覧</title> </app:collection> </app:workspace> </app:service> </entry>
これで、"作成する"という意味語リソースのエントリを見ると、コメントリソースと訳語リソースが存在している事が分かります。
Viewはrxmlで書いているので、次のような感じになります。
xml.instruct!(:xml, :version => 1.0, :encoding => 'utf-8') xml.entry(:language => 'ja', 'xmlns' => 'http://www.w3.org/2005/Atom', 'xmlns:app' => 'http://www.w3.org/2007/app') do |entry| entry.id('tag:tom@nadukete.name,2008:meanings/'+@meaning.id.to_s) entry.updated(@meaning.updated.localtime.iso8601) entry.author do |author| author.name(@meaning.author) end entry.title(@meaning.name) entry.content(@meaning.comment, :type => 'text') entry.link(:rel => 'edit', :href => meaning_url(@meaning.name)) entry.tag!('app:service') do |service| service.tag!('app:workspace') do |workspace| workspace.title(@meaning.name) workspace.tag!('app:collection', :href => meaning_url(@meaning.name)+'/comments') do |collection| collection.title('「'+@meaning.name+'」のコメント一覧') end workspace.tag!('app:collection', :href => meaning_url(@meaning.name)+'/namedwords') do |collection| collection.title('「'+@meaning.name+'」の訳語候補一覧') end end end end
更に、訳語リソースも子リソースとして、コメントリソース・スターリソースを持っているんですが、それも同様の考え方でいけそうですね。
あとがき
たけまるさんの記事では、その後の動向として別の記事で、「OpenSocialでは、AtomPubのサービス文書の問題の解決の為に、XRDS-Simple+URI Templateを使う事になった。」と書かれています。
この辺りはまだちょっと調べ切れていなくて、自分の記事では取り上げられなかったんですが、もう少し調べて、また記事のネタにしてみようかなと思います。
次回は?
サービス文書を提供する事で、親リソース→子リソースという方向の関係性を示す事はできるようになりましたが、今のままでは、RESTfulWebサービスの接続性について十分な考慮がされているとは言えません。
次回は、各リソース間の接続について書きたいと思います。