たけまる / OpenSocial/GData で Google は MS の道を歩むのか?
2007-11-29
_
OpenSocial/GData で Google は MS の道を歩むのか? [gdata][atom][atompub]



狙ったようなタイトルですが,AtomPub と GData (Google Data APIs) のdiff を取ってみましたっていうエントリです (何の役に立つかわかんない
けど,誰かやっといた方がいいと思うので).
OpenSocial が GData ベースということもあって,GData への注目が復活
しているようです.ちなみに,GData は AtomPub をベースにしています.
ところが,有り体に言えば現在の GData には AtomPub と矛盾する点があ
り,相互運用が難しいです.まぁ,GData のほうが先に完成した (古い
AtomPub をベースにした) ので,仕方ないのですが.
この先,Google が AtomPub という標準に準拠するのか,あるいは独自仕
様を押し通してしまうのか (evil になるのか?),どっちなんでしょう.な
んとなく,10年前のMSを彷彿とさせる雰囲気があります.
AtomPub と GData の比較はすでに [2007-01-07-1] で行ったのですが,今
回は OpenSocial で変更になる (と思われる) 点も含めて,わかりやすく
まとめ直しておきます.
なお,GData はサーバとの通信方法を定めたコア仕様と,カレンダーやス
プレッドシートのようなデータ種ごとの個別仕様とがあります.ここでは
コア仕様のみを扱います.
# 仕様書のみを参考に書いたので,実際の GData サーバとは違うとこもあ
# るかもです.気づいたら教えてくださいませ m(_ _)m
GData 仕様の全訳は [2007-01-06-1] にありますので,適宜参照してくだ
さい.
■ キャッシュ,バージョン管理
明らかに異なるのがこの点です.Google も認識していて,GData Blog に
もそのような記述があります.
Official Google Data APIs Blog: It's Official
A big part of that work involves a lot of careful thinking about
how to support the final version of the protocol and also support
our existing clients. I'll talk more about our versioning strategy
in a later blog post.
[2007-11-27-1] に書いたように,AtomPub ではバージョンを表すのに
ETag/Last-Modified header を使います.これに対して,GData では URI
の一部を使います.
たとえば,リソース URI が http://example.com/collection/1.atom だと
すると,最初のバージョン (ver.1) を表す URI は次のようになります.
http://example.com/collection/1.atom/1
"リソースを一意に表す" という URI (ひいてはREST) の思想に基づくと,
バージョンを含めてしまったのは失敗だと思います.どうしてもバージョ
ンを URI で指定するのなら,"?version=1" のようにパラメータとすべき
でした.
また,AtomPub ではバージョン (ETag/Last-Modified) を要求されるのは
PUT のみですが,GData では PUT と DELETE になります.
AtomPub と GData に互換性を持たせることはできるでしょうか? 幸いなこ
とに,どちらでもバージョン管理はオプショナルな仕様となっています.
現時点で互換性を持たせるには,バージョン管理を行わないという選択肢
しかないように思います.
■ Collection URI (POST URI)
AtomPub でリソースを作成するときは,Collection URI に POST します.
すると,リソースの URI が与えられ,その URI に対して GET や PUT が
行えるようになります.
たとえば,http://example.com/collection/ という Collection URI に
POST すると,サーバによって http://example.com/collection/1.atom と
いう URI が与えられます (ディレクトリとファイルの関係に似ています).
従来の GData 仕様は AtomPub と同じでした.しかし,OpenSocial では変
更になるのかもしれません.OpenSocial 仕様によると,POST のときにリ
ソースの URI を指定してしまうように読めます (単なる typo かもしれま
せんが).つまり,http://example.com/collection/1.atom に POST する
ということです.
この点については [2007-11-04-1] "Data - Activity" の項に詳しく書き
ましたので参考にしてください.
■ atom:category
GData では atom:category 要素を2つの異なる意味で使います.
atom:category/@label 属性があるときは,通常のカテゴリ (いわゆるタグ)
として使います.これは,通常の Atom としての使い方になります.
atom:category/@label 属性がないときは,データの種類を表すために使わ
れます.たとえば,次の要素を持つ Entry はイベントを表します.
<category scheme="http://schemas.google.com/g/2005#kind"
term="http://schemas.google.com/g/2005#event"/>
ダブルミーニングでわかりにくいというのはさておき,先日の
Interop [2007-11-15-1] でもう一つの問題が明らかになりましあ.
atom:category をデータ種を表すために使うときには,
atom:category/@scheme を "http://schemas.google.com/g/2005#kind" に
設定しなければなりません.Google としては,POST 可能な @scheme を限
定したいようです (atom:category/@term は open にしたい).しかし,現
在の Service Document では @scheme のみを限定することができませ
ん (@term とペアで限定することはできます).
最近まで AtomPub ML で議論されていましたが,"現在の AtomPub ではで
きない" という結論になりました.
とりあえずの解決策は,Service Document ではなく POST のレスポンスで
atom:category を限定する (都合の悪い atom:category を受信したらエラー
を返す) といったところでしょうか.
■ Service Document
GData と OpenSocial の仕様には Service Document についての記述はあ
りません.
しかし,Service Document を用意するのは簡単ですし (上記の
atom:category 問題は置いといて),Interop [2007-11-15-1] で使われた
開発中 Blogger には実装されていたっぽいので,いずれ解決されると思い
ます.
