RESTfulWebサービス読書会第5回に行ってきた

今回は(今回も?)、読書会というよりは、おしゃべり会みたいな感じで、AtomPubの話題を中心にREST議論をしてきました。

話の中心は、「はてなダイアリーのAtomPubって何か気持ち悪いよね」という話題でした。

もう既に各所で言われている話とは思いつつも、自分でリソース設計とかする時の参考になるかも、という期待を沿えて、簡単に書いておこうかと思います。

まずは、はてなダイアリーのAtomPub対応の仕様へのリンクを貼っておきます。
はてなダイアリーAtomPubとは - はてなキーワード

話に挙がった"気持ち悪さ"の一番は、下書きエントリーを公開する時のやり方で、こんな感じのリクエストを投げるようになっています。

PUT /はてなID/atom/blog/20080101/XXXXXXXX
X-HATENA-PUBLISH: 1

※話の中で挙がったんですが、"blog"は"draft"の間違いですよね…きっと…。

こういう仕様になったのは、色々と都合もあっての事だとは思うんですが、せっかくAtomPubに対応したのに、AtomPubの仕様として用意されている下書きの機能(app:draft)を使わずに、下書きという別リソースにしたのは何でだろうね?…という辺りがその場でのみんなのツッコミどころでした。

想像するに、はてな"ダイアリー"である以上、日付ベースのデータ管理になっていて、今更、他の形式の管理には変えられないというのが一番のネックになっているんだろうなとは思いますが…。

で、AtomPub的にどうかというのは置いておいたとして、記事リソースと下書きリソースという2つのリソースに分けるというリソース設計なんだという立場で見たとしても、"X-HATENA-PUBLISH"という独自のヘッダを使うのは、REST的に美しくないよね…という話もしました。

あと、リソース設計する時に気を付けないといけないなと思った点として、例に挙げた下書き公開操作は、結局のところ、

  • 下書きリソースの内容を取得
  • その内容で新しく記事リソースを作成
  • 下書きリソースを削除

という3つの動作が内部的に行われる事になるはずなので、最初、「GET→POST→DELETEってクライアント側がリクエストを投げるようにすればいいんじゃないの?」と思ってしまったんですが、いずれかのリクエストが失敗した時の整合性が取れなくなってしまうので、これら3つは一連の操作として行われなければいけないんですね…。

こういった、"下書き"→"公開"みたいに、状態を別リソースとして定義していて、その状態を変化させるリクエストを投げたい場合は、状態変更専用のリソースを別途定義しておいて、パラメータとして元の状態のリソースのURIを渡す…というのがスマートな方法かなという話になりました。

はてなダイアリーの場合だと、

PUT /publication?drafturi=/はてなID/atom/blog/20080101/XXXXXXXX

みたいな感じ?*1

まぁ、今までRESTfulな読書会をずっとやってきていて、「何を今更…」と言われそうですが(^^;、具体例としてこういった事例を見ないと、なかなか感覚的に分からないので、今回、目の前にある具体例として、はてなダイアリーのAtomPub実装をベースに議論できたのは良かったなぁと思います。

という訳で、「やっぱり具体的にやってみなきゃ分かんないところも多いよね…」という事もあるし、ちょっと作りたいサービスもあったので、バックエンドをRESTfulに設計してみようかなと思って、今日はインフラ部分を色々とやっていました。

自分で一から実装するのは面倒臭いし、せっかくの機会だからと思って、まだ右も左も分かっていないRailsに手を出してみた訳ですが、Railsとは直接関係無いところで色々と時間を掛けてしまい、やっとこさ「scaffoldで作ったbookmarkリソースにGETしたら、XMLで結果が返ってきたよ、わ〜い♪」というところに辿り着いた辺りで力尽きてしまいました。(^^;ゞ

Rails(およびRuby)はまだ全然分かってないので、勉強しつつボチボチやっていこうと思います。

*1:でも、「状態を変える」という動詞的な意味合いが強い感じがするから、何となく違和感があるような気がしてしまうなぁ…。(^^;