HTTPメソッドの正統的使い方と現実的対処法

「最小抽象ファイルシステムの仕様案 その2」 に書いたように、ファイルシステムAPIとHTTPを関係付けようとしてます。そこで、id:yoheiさん監訳の『RESTful Webサービス』を拾い読みしてみました*1。

RESTful Webサービス

それで知ったり考えたりしたことを以下に書きます。

HTTPクライアントとしてブラウザを使うときの問題点

HTTPメソッドの本来の意味／使い方は次のようらしいです。

HTTPメソッド	意味／使い方
GET	リソース（の表現）を取得する
PUT	新しいリソースを作る／既存リリースを上書き変更する
DELETE	リソースを削除する
HEAD	リーソースのメタデータを取得する
POST	新しいリソースを作る

新しいリソースを作る際のPUTとPOSTの違いは：

• 新しいリソースのURIをクライアント側で指定できるときはPUT
• 新しいリソースのURIをサーバー側で決定するときはPOST

本来の意味／使い方に沿ってHTTPメソッドを使う上で、次の2つの障害があります。

1. 現状のHTMLとブラウザは、GETとPOSTしかサポートしてない。
2. 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は次のような使い方をされているようです。

1. 新しいリソースを作る。そのURIはサーバー側で決める。
2. 既存のリソースにデータを追加する。
3. 任意の処理プログラムにデータを渡す。

この3つ（もっとあるかも知れませんが）の作業は、いずれも POST URI によってトリガーされます。用途を区別する方法はありません。そこで、トンネリングと同じような発想で、次のようなクエリ文字列を付けてはどうでしょう。

1. POST URI?_submethod=generate
2. POST URI?_submethod=append
3. POST URI?_submethod=process

POSTのオーバーロード（トンネリング）と、POSTの細分（サブメソッド化）を組み合わせると、概念的には7つのメソッドが生じます。

1. get
2. put
3. delete
4. head
5. generate
6. append
7. process

こう考えてみても、サーバー側でなんかめざましいことが出来るわけでもないので、半分は気分（精神衛生）の問題ですが、クエリ文字列まで含めたURIのなかに「何を要求しているのか」「何がされるべきなのか」という意図がエンコードされるのは良い事だと思いますが、いかがでしょう。

*1:主に、p.101「統一インターフェイス」のあたりです。