GETとPOSTだけでRESTfulなサービスを作れるか

作者 Dilip Krishnan , 翻訳者 徳武 聡 投稿日 2010年6月29日

セクション

エンタープライズ・アーキテクチャ,

設計/アーキテクチャ

トピック

SOA ,

REST ,

エンタープライズアーキテクチャ ,

Architecture ,

サービスデザイン

共有 |

原文(投稿日：2010/06/23)へのリンク

GETとPOSTしか使えない環境でRESTfulなサービスを開発する方法を調査する記事のなかで、Mike Amundsen氏が、GETとPOSTだけでRESTfulなサービスを作れるかどうか尋ねている。

時々、HTTPメソッドのPUTとDELETEを使っていなければRESTfulなアプリケーションではない、と思い込んでいる人とRESTfulのアーキテクチャスタイルについて議論になります。この思い込みは正しくありません。

この問題に答えようとして氏が行ったのは、正しいHTTPメソッドを適切な処理に利用する限り、そのサービスはRESTFulでありうるということを検証するための2、3の質問に答えることだ。

安全か。

氏はHTTPメソッドの検証を行うことで、手段がオペレーションの安全性を決定するということを理路整然と主張している。つまり、HTTPメソッドを通じて表現されるオペレーションの意図とそのリクエストの実装が一致していれば、オペレーションは安全だと考えられる。

重要なのは、安全ではないオペレーション(例えばデータの書き込み)を行うのに安全なHTTPメソッド(例えばGETとHEAD)を利用しないということです。[…] HTTPではGETは"安全"と定義されているので、キャッシュやその他の代替リソースは、必要に応じてURIそして/またはキャッシュを"プリフェッチ"したりレスポンスを再生したりすることは問題ないと(仕様にしたがって)想定しています。

POSTでは不十分か。[安全でないオペレーションにはPUTとDELETEを使ったほうがいいのか。]

この議題についてはたくさんの事例や文献がPOSTだけでは不十分であることを示しているが、氏はRESTfulなサービスのインターフェイスがいつもCRUDと一致するとは限らないことを強調する。

[…] もうひとつ、すべての書き込み処理にPOSTだけを使っているサービスはRESTfulではない、という一般的な考えがあります。つまり、PUT そして/または DELETEを使っていなければRESTをサポートした実装とはいえない、という考えです。この間違った思い込みはRESTをCRUD処理の観点だけから見ることによる副作用です。REST == CRUD over HTTPという見方の副作用なのです。HTTPを通じてCRUDを行うことは可能ですが、それはRESTではありません。それはCRUD over HTTPなのです。

氏はRoy Fieldingの“POSTをつかうのはOKだ”という記事を引用して次のように続ける。

HTTPで状態を変更する処理のすべてにPUTを利用する必要はありません。RESTもそのようにすべきだと規定しているわけではありません。

しかし、本当にGETとPOSTだけですべての処理ができるのか。

“もちろんできます。”と氏は言う。“この方法で長年やってきました。他の魔法は必要ありません。特別なヘッダも必要ありません。URIのアクションの引数も必要ありません。メッセージのボディにメソッドの引数を含める必要もありません。”続けて氏はサーバー上で待ち行列型の処理で書き込みを行う例を挙げて説明する。

例えば、公開リソースをサーバーに書き込んで公開するには処理対象のリクエストのリストに書き込みリクエストを追加して、そのリクエストを通じて書き込みを実現します。

  POST /users/pending-updates/
  OR
  POST /users/pending-deletes/

このモデルはTim Bray氏がSunのVM APIの設計で提唱した考えととても似ている。>Tim Bray氏はこの考えを遅いRESTと呼んでいる。この考えはCraig McLanahan氏の非同期処理のリクエストの扱い、という提案に基づいている。

すべてPUT/POST/DELETEメソッドでの処理で、“202 In progress”と“状態”をあらわす新しいリソースを返します。このリソースには進捗を0から100までの値であらわす指標progressと、処理対象のtarget_uri、処理を特定するopを含んでいます。progressが100になるとstatusとmessageの値で処理結果がどうなったか確認できます。これはクライアント側の実装者が簡単にポールできるフックを設計するためのアイディアです。

Mike Amundsen氏はこの記事で次のように結論づけている。HTTPメソッドの仕様がネットワークによって制限されていたり、クライアント側のユーザエージェントが標準的なGETとPOST以外は扱えないというような制限がある場合に備えて、サービスはクライアントをHTTPメソッドとURIの正しい表現へと案内する調整機構を作成する必要がある

HTTPはURIを使ってリソースとその表現を指し示すことにより、通信を抽象化しています。したがって、実行時に調整を行う仕組みは実現可能なだけではなく、そのような仕組みはプロトコルの中に組み込まれています。この水準の抽象化とFielding氏の論文で説明されているハイパーメディアの制約を合成することでHTTPに準拠し、複数の環境下でRESTアーキテクチャスタイルの原則をサポートするとても柔軟な実装を実現できます。たとえGETとPOSTしか使えないという制約があったとしても。

元の記事と同様にこの記事にもあなたの意見を聞かせていただきたい。