Hatena::ブログ(Diary)

winplusの日記 このページをアンテナに追加 RSSフィード

2012-07-16

RPCのHTTP風正書法

※抽象的な部分をとばして、比喩をそのまま受けとるという、檜山さんには非常に失礼な記事になっております。申し訳ございません。

先の記事(ハイパーリンクはリソースを繋ぐ - winplusの日記)にid:tkawaさんにコメントをいただき、もうすこし考えてみました。とくにRESTといわず、ROAと逃げたところ。ご了承ください。

追記

RESTfulなリソースとURIについては、iwamotのブログ : リソースとURIとクエリストリングの話をご参照ください。わたしの理解が不十分だったため、以下の記事には間違っている箇所があります。

「リソース」と「リソースの表現」

あるブログの記事がHTML形式とJSON形式で取得可能だとしましょう。

HTML形式

http://hiyama.example.com/blog/entry123

Accept: text/html

JSON形式

http://hiyama.example.com/blog/entry123

Accept: application/json

ブログの記事がリソースであり、HTML形式とJSON形式のデータはそれぞれリソースの表現である、ということで問題ないと思います。

では、以下の形式で取得できる場合は、どうでしょうか。

HTML形式

http://hiyama.example.com/blog/entry123.html

JSON形式

http://hiyama.example.com/blog/entry123.json

さて、これらは別の「リソース」なのか、それとも別の「リソースの表現」なのか。

HTML形式

http://hiyama.example.com/blog/entry123?type=html

JSON形式

http://hiyama.example.com/blog/entry123?type=json

この場合はどうでしょうか。

やはり「ブログの記事がリソースであり、HTML形式とJSON形式のデータはそれぞれリソースの表現である」といいたいですね。コンテントネゴシエーションをURLを借りて行っているだけだと。なので、たとえば、http://hiyama.example.com/blog/entry123.jsonへのリンクがあったとしても、リソースの表現へのリンクではなく、あくまでリソースへのリンクと考えます。

さて、今回のケースです。

「編集可能なようにフォームを含むHTML画面」は、同一リソースの別表現とも解釈できます。

id:tkawaさんのコメント

EDIT形式

http://hiyama.example.com/blog/entry123?type=edit

これまでと同じように、これも「リソースの表現」といっていいのかどうか、わかりません。たしかに、データー内容は同じブログ記事を元にしていて、しかもそのブログ記事を修正するためのものなので、「同一リソースの別表現」ともいえるのかもしれません。しかし、これはコンテントネゴシエーションの範疇をこえているような気もします。やはり編集画面という別リソースだと考えるのがRESTfulだと思います(さきの記事ではRESTを避けてROAとしていましたが、ここではRESTfulとさせてもらいます)。

RPCのHTTP風正書法

といっても、編集画面を「同一リソースの別表現」だと考える方向性もアリだと思います。

こちらのリソースを<リソース>と表記すると、あるブログの記事という<リソース>から、編集画面という「<リソース>の表現」を取得するという操作をおこなう、その操作には<リソース>を特定するURLにたいして動詞editを発行する、となります。<リソース>が直観的なのが、このやり方の利点でしょう。編集画面が別リソースという考え方は、あまり自然な感じがしません。

もっといえば、<リソース>は“実体”であり、「もの」であり、オブジェクトなのです。リソースはそうではありません。

たとえば、RESTが推奨する立場を、以下のようなものだとしましょう(カジュアルな理解としては間違っていないと思います)。

  • リソースにはぜんぶURLをつける。つまりURLでリソースを識別できるようにする。
  • URLにはリソースを識別するため以外の情報はもたせない。たとえば、HTTPには動詞を扱う方法が定義されているんだから、リソースの操作にはそれを使おう。

これは「HTTPをちゃんと使う」とまとめることができるでしょう。これを先の<リソース>にあてはめるとこうなります。

URLのパス部分
<リソース>の識別子
動詞
<リソース>への操作
クエリー
<リソース>への操作の引数

これは、以下と同じです。

URLのパス部分
オブジェクトID
動詞
オブジェクトのメソッド
クエリー
メソッドの引数

これはたしかに「きれい」です。しかしRESTというよりも、RESTが推奨することを参考にしてオブジェクト指向プログラミングモデルにおけるRPC(RMI)をHTTP風に記述する正しい方法を定義した、とみなすべきでしょう。もちろん、だから劣っているとか駄目だとかいっている訳ではありません。

まとめ

  • リソースと<リソース>は異なる概念である。
  • <リソース>のほうが直観的である。
  • RESTでは、ハイパーリンクは<リソース>ではなくリソースをつなげる。
  • RESTでは、<リソース>を取り扱わない。

ちなみに「アプリケーション状態エンジンとしてのハイパーメディア」というのは、アプリケーション状態はすべてリソース(≠<リソース>)として存在しているため、リンクをつうじてリソース間を移動することがそのままアプリケーション状態の遷移となる、ということだと理解しています。

スパム対策のためのダミーです。もし見えても何も入力しないでください
ゲスト


画像認証

Connection: close