第3回RESTful本読書会に参加した
第1回から参加していますが、今回が一番濃かったかも（特に懇親会が）。
感想というか、色々思うところがあったのでメモ。
ブックマークリソースのURI問題
「7.3.3 ブックマークコントローラ」において、ブックマークがユーザーアカウントの従属リソースとなっていることに対し、id:n_shuyoさんが異議を唱えられた。私も、自分が実装するなら、ユーザーの従属リソースにはしないなあ。
というか、まず「例7-1」のDB設計がおかしくないか。私なら下記のようにする。
- users
- user_id, name, full_name, email, password
- uris
- uri_id, uri, uri_hash
- bookmarks
- bookmark_id, user_id, uri_id, short_description, long_description, timestamp, public
ブックマークのファクトリリソースは/bookmarks、ブックマークリソースは/bookmarks/{ユーザー名};{URI-MD5}にする。/bookmarks/{ブックマークID}でもいい。
空PUT問題
「8.6 統一インターフェイス」にある「表現を伴わないPUTリクエストは、単にリソースが特定のURIに存在することのアサーションである」という記述について、id:t-wadaさんが意味を問われていた件。
4章の発表担当だった私が気づくべきでしたが、これは「4.8.1 GET、PUT、DELETE」にある、S3のバケット作成のようなケースを指しているのではないでしょうか。
バケットのURIを指定すると、その表現を指定したことになる。ほとんどのリソースに対するPUTリクエストでは、表現が含まれたエンティティボディが送信されるが、これは必須ではない。
前掲文中の「アサーション」は「表明」ぐらいの日本語に訳されていてもよかったように思います。
Why REST?
懇親会でid:n_shuyoさんが熱く語られた「なぜRESTfulに実装するのか」の話を興味深く聞きました。私なりにまとめると「HTTPの発明者は、現在のインターネットの姿を想像もしていなかっただろう。RESTもそのようなポテンシャルを秘めているのではないか。未来の、そして未知のクライアントに向けてRESTfulに実装することに意味があるのだ」ということです。
ツンデRESTのデレの部分が遺憾なく発揮された瞬間といえよう。
REST王子
懇親会の終了間際にはid:nishiohirokazuさんがいかに可愛いかという話題で持ちきりとなり、「西尾さんはREST王子」との歓声が店内にこだました。
追記（2008-06-17）
空PUT問題について、id:ZIGOROuさんにコメントをいただきました。
> 表現が含まれたエンティティボディが送信されるが、これは必須ではない。
http://d.hatena.ne.jp/IwamotoTakashi/20080614/p1#c1213671289
だとすると「石橋を叩いたリクエスト」って意味合いですかね。
なるほど、それも空PUTですね。見落としてました。
私の理解はもっと単純で、以下のような感じです。
S3のバケットが例として分かりやすいので、表3-1を見ます。すると、バケットのPUTは「作成」のみであることが分かります。既存バケットのURIにPUTしても、たぶん「405 Method Not Allowed」が返るのでしょう。
同じ表によれば、バケットURIのGET時にはオブジェクトリストが返ります。バケットの作成直後はオブジェクトがひとつも存在しないので、オブジェクトリストは空です。なので、バケットの作成を空PUTで行うのは自然だと思います。
このような空PUTを指して、著者は「単にリソースが特定のURIに存在することのアサーション」と表現しているのではないでしょうか。ここでの「アサーション」は、プログラム言語とは無関係な、一般言語の「assertion」の意味（「主張」とか「断言」とか）だろうと思います。
