2012年07月

ハイパーリンクは「状態の表現」をつなぐ

RESTful Webアーキテクチャにおいて、a要素やform要素に代表されるハイパーリンクがつなぐものは、リソースではなく「状態の表現」である。例として、POSTメソッドのレスポンスを考えると分かりやすい。ユーザがとくに知りたいのはPOSTの結果がどうなったかだ。サーバは、結果を表すリソースのURIをLocationヘッダで返すことも可能ではあるが、レスポンス自体に結果を含めてもよい(むしろ後者のほうがよく見かける)。このときレスポンスは「POSTの結果がどうなったか」をあらわす状態の表現であり、リソースそのものではない。

GETでも事情は変わらない。そもそも、リソースは転送(Transfer)されないのだ。転送されるのは状態の表現(Representational State)でしかない。

URI are identifiers of resources.  GET is a request for a
representation of the current state of the identified resource.
The server does not transfer the resource itself because that's
not what the client requested; the client does not want the
mechanism that implements the resource over all time -- only the
current state of the resource at that instant in time.  That's
what allows the client, and the transfer protocol, to be simple.

Re: resource and representation from Roy T. Fielding on 2002-07-08 (www-tag@w3.org from July 2002)

リンクが含まれるのも状態の表現だし、リンクを通じて得られるものもまた状態の表現なのである。

先日「ハイパーリンクは何をつないでもいい」を書いた時点では、このことが理解できていなかった。

「接続性」が誤解のもと

ハイパーリンクはリソースをつなぐべき、と僕が誤解してしまったのは、『RESTful Webサービス』で定義された「接続性」(Connectedness)が原因かもしれない。同書100ページに「リソースの接続性」とあるし、128ページには「リソースからリソースへの移動」とも書かれている。著者の意図はともかく、これらの記述から、リソース同士をつなぐのはハイパーリンク、というメンタルモデルが僕のうちにできてしまった可能性は大いにある。

Roy T. Fieldingは、接続性の定義に批判的だ。「アプリケーション状態エンジンとしてのハイパーメディア」を「接続性」と呼び替えられると、ハイパーメディアの駆動力としての役割が不明確になってしまう、というのだ(On software architecture - Untangled)。「ROAはリソースを重視しすぎだ」とも言っている。その弊害のひとつが、僕の誤解に現れてしまったのかもしれない。

リソースとURIとクエリストリングの話

RPCのHTTP風正書法 - winplusの日記」を読んで、論旨とは無関係に気になった点があったので、例によってRoy T. Fieldingの意見を調べた。

  • http://example.com/blog/entry123.html
  • http://example.com/blog/entry123.json

上記の2つのURIは、それぞれ異なる2つのリソースを示す(参考1参考2)。

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

上記の2つのURIも、それぞれ異なる2つのリソースを示す。ただし、望ましいクエリストリングの使い方とはいえない(参考3参考4)。

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

上記のURIも、もちろん異なるリソースを示す。ただしこれも、望ましいクエリストリングの使い方とはいえない。

というわけで、望ましいURIは下記のようなものだろう。

HTML形式のブログ記事リソース
http://example.com/blog/entry123.html
JSON形式のブログ記事リソース
http://example.com/blog/entry123.json
ブログ記事編集画面リソース
http://example.com/blog/entry123/edit

まとめ

  • 2つのURIをGETするとして、それぞれに異なる応答が期待されるのなら、それらは異なるリソースを示す
  • クエリストリングはクエリにのみ使うべし

Roy T. Fieldingはそう言っている。

ハイパーリンクは何をつないでもいい

ハイパーリンクはリソースをつなぐべき、という指針はRESTの統一インターフェース(Uniform Interface)制約をWebシステムのアーキテクチャに適用したときに導かれるものだ。RESTのスタイルに関心がない、言い換えればスケーラビリティにこだわりのないAPI設計者が、RPC的にURIやHTTPメソッドを使うのは自然なことだろう。

僕自身はスケーラビリティよりもRESTのシンプルさに惹かれている。API設計をドライブしてくれる感じがするからだ。ハイパーリンクはリソースをつなぐべき、という指針には特に疑問を持たないし、これからも従っていくつもりだ。

プロフィール

ENECHANGE株式会社VPoT兼CTO室マネージャー。AWS Community Builder (Cloud Operations)。前職はAWS Japan技術サポート。社内外を問わず開発者体験の向上に取り組んでいます

カテゴリ別アーカイブ
月別アーカイブ
ブログ内検索