状態のPOSTが適切なのはどういうとき？

作者 Dilip Krishnan , 翻訳者 菅野 裕 投稿日 2009年4月15日 午後8時39分

コミュニティ

SOA

トピック

REST ,

デザインパターン ,

設計

原文(投稿日：2009/4/2)へのリンク

Tim Bray氏がある記事で(リンク)Sun CloudのAPI (リンク)の最初の公開ドラフトからのフィードバックについて検討している。彼はその記事でフィードバックに対して回答する中で、クラスターにVMを作るといった相互作用のモデル化の方法について、RESTfulな方法を検討した。

彼はSunのクラウドAPIの設計というコンテキストにおけるいくつかのシナリオを挙げ、そのような相互作用をモデル化するのに状態をPOSTすることが適切な方法なのかどうかを問いている。

しかし実際に状態を変更させようとするわけではありません。要求したのは一連の特定のアクションであり、結果として状態が目的とする値に達したり、または達しなかったりするのです。たとえば、「デプロイ」スイッチを押せば状態は「デプロイ中」に変わり、そして幾ばくかの時間が経った後「デプロイ完了」になります。また「リブート」操作も赤い大きなスイッチを持っている、同じ側の典型的な例です。問題なのは、このスイッチをどうやって押すかです。

私は考えれば考えるほど、これらのリソースはボタンのようだと思えてきます。定義された操作は1つだけ、「押す」だけです。人々は「write-onlyなリソース」のことに愚痴をこぼしてきましたが、私にはこれは間違いないものであり問題とは思えません。リブートや停止ボタンはいかなる状態も実際にはもっておらず、そのためGETでいかなる有用な情報が得られることを期待すべきではないのです。

Bill de hÓra氏はこの記事に反応し(リンク)、例を挙げながらPUTとPOSTの違いと、一方が他方より適切であるのはどの場合かを説明している。

どのようなときにPUTとPOSTが実際に重要となるのでしょう？私が自信を持って言える限りでは、扱うリソースがコレクションのときです。これは非常にありふれています。フォルダーやアルバム、フィード、コレクション、ブログ、タグクラウド。注文、ショッピングカートなど、あらゆるリストベースの構造です。

彼はまた議論全体のより実践的な側面を示し、1つの解決法としてフォームをPOSTすることを提案している。

一方で多くの、非常に多くの人がREST/HTTP/AtomPubの深い領域のこと気にしておらず、また気にしようともしていません（またはできません）。私たちに必要なのは開発者がすぐに使えるようになるパターンとプラクティスではないかという考えを私はいくらか感じています。

しかし現状ではRESTコミュニティの専門家である私たちも、リソースを部分的に更新するよい方法やデザインパターンを持っているとは言えません。それが提供できるようになるまでは、もっとも簡単で、すでに配備されたクライアントライブラリやWebフレームワークで広く利用できるアプローチであるフォームのPOSTが使われるだろうと予測しています。そうでなければ、部分的な更新のための特別なメディアタイプを定義するかです。

Roy Fielding氏も同様に記事に対して反応している(リンク)。

（私の主張において）メソッドの利用における厳密さに欠ける主な理由は、HTTPで定義されるメソッドがWebアーキテクチャの定義の一部であり、それがRESTアーキテクチャの方法ではないからです。個別のメソッド定義は（中略）RESTアーキテクチャスタイルのことを問題にはしていないし、それについて議論するのは難しいのです。唯一RESTが要求しているのは、すべてのリソースを統一されたメソッドで扱えることなのです（言い換えれば、仲介者はリクエストの意味を理解するためにリソースの型を知る必要がないのです）。

POSTが問題になるのは、他のメソッドが理想的に適している状況で使われるときだけです。他のメソッドが仲介者にとってより価値あるものになるのは、それらが失敗を自動で処理する方法や中間キャッシュがそれらの振る舞いを最適化する方法について何かしら表現しているからです。POSTはそのような特徴を持ちませんが、それが私たちがPOSTなしでいられることにはなりません。POSTはHTTPにおいて、「統一する価値のないアクション」といった汎用的なものを含むたくさんの有用な目的を果たしています。

Roy氏は彼の回答として次のようにまとめています。

私たちはHTTPの状態変更のすべてのPUTを使う必要はありません。RESTはそうすべきとは決して言っていません。（中略）個人的には、そのようなボタンにはPOSTを使うでしょう。APIは、クライアントがより大きなリソースの状態表示をリフレッシュすべきだというメッセージを含めて応答することで、POSTの利用を埋め合わせることができます。言い換えると、303レスポンスを返してそのVM状態の表示へリダイレクトすることで、クライアントは状態が変わったことを知ることができるのです。

元の記事はこちら (リンク)にて、コミュニティの反応も一緒に読むことができる。

• 次へ >