「最小抽象ファイルシステムの仕様案 その2」 に書いたように、ファイルシステムAPIとHTTPを関係付けようとしてます。そこで、id:yoheiさん監訳の『RESTful Webサービス』を拾い読みしてみました*1。
- 作者: Leonard Richardson,Sam Ruby,山本陽平,株式会社クイープ
- 出版社/メーカー: オライリー・ジャパン
- 発売日: 2007/12/21
- メディア: 単行本
- 購入: 25人 クリック: 842回
- この商品を含むブログ (168件) を見る
それで知ったり考えたりしたことを以下に書きます。
HTTPクライアントとしてブラウザを使うときの問題点
HTTPメソッドの本来の意味/使い方は次のようらしいです。
HTTPメソッド | 意味/使い方 |
---|---|
GET | リソース(の表現)を取得する |
PUT | 新しいリソースを作る/既存リリースを上書き変更する |
DELETE | リソースを削除する |
HEAD | リーソースのメタデータを取得する |
POST | 新しいリソースを作る |
新しいリソースを作る際のPUTとPOSTの違いは:
本来の意味/使い方に沿ってHTTPメソッドを使う上で、次の2つの障害があります。
- 現状のHTMLとブラウザは、GETとPOSTしかサポートしてない。
- POSTには、リソース生成以外にも典型的な使い方がある。
複数のメソッドを無理矢理にGET/POSTに乗せる
最初の問題は、「POSTのオーバーロード」とか「トンネリング」という手法で対処するようです。例えば、URIのクエリ文字を ?_method=put とすると、このリクエストがPOSTで送られていても、「意味的にはPUTとみなす」というものです。この手法を使っていいケースはおそらく次のようになるでしょう。
\ | get | put | delete | head | post |
---|---|---|---|---|---|
GETに乗せる | - | × | × | ○ | × |
POSTに乗せる | - | ○ | ○ | △ | - |
この表で、「ハイフンはやってもしょうがない / ×はやってはいけない / ○はやってもよい / △は実害はないだろう」という意味です。(こんな表が『RESTful Webサービス』に載っているわけではありません。)例えば、GET URI?_method=head はやってもよさそうだが、GET URI?_method=delete はダメってことです。
このトンネリングの手法でリクエストを作るときは、次のようになります。
本来のメソッド | トンネリングを使ったリクエスト |
---|---|
GET | GET URI |
PUT | POST URI?_method=put |
DELETE | POST URI?_method=delete |
HEAD | GET URI?_method=head |
POST | POST URI |
ただし、HEADをGETに乗せたリクエストの場合、本来のHEADとして処理されるならばレスポンスヘッダしか戻ってきません。これは、ブラウザを使っている人間にとっては不便だなー、と思います。メタデータを表示可能な形にエンコードしたもんをレスポンス・ボディに含めちゃまずいんでしょうか?
POSTの用途を細分して知らせる
現状、POSTは次のような使い方をされているようです。
- 新しいリソースを作る。そのURIはサーバー側で決める。
- 既存のリソースにデータを追加する。
- 任意の処理プログラムにデータを渡す。
この3つ(もっとあるかも知れませんが)の作業は、いずれも POST URI によってトリガーされます。用途を区別する方法はありません。そこで、トンネリングと同じような発想で、次のようなクエリ文字列を付けてはどうでしょう。
POSTのオーバーロード(トンネリング)と、POSTの細分(サブメソッド化)を組み合わせると、概念的には7つのメソッドが生じます。
- get
- put
- delete
- head
- generate
- append
- process
こう考えてみても、サーバー側でなんかめざましいことが出来るわけでもないので、半分は気分(精神衛生)の問題ですが、クエリ文字列まで含めたURIのなかに「何を要求しているのか」「何がされるべきなのか」という意図がエンコードされるのは良い事だと思いますが、いかがでしょう。