BT

マージか、置き換えか、パッチか:Astoriaはデータの更新をどう扱うか

| 作者: Jonathan Allen フォローする 595 人のフォロワー , 翻訳者 菅野 裕 フォローする 0 人のフォロワー 投稿日 2008年7月3日. 推定読書時間: 2 分 |

RESTを使っている際、既存のデータの更新にPUTメソッドを使うと何が起こるのがふさわしいだろうか?Astoriaチームはこの問いについて考え、1つの結論を出した。

AstoriaベースのWebサービスにおいて、PUTメソッドを受けた際の更新処理の扱い方には、2通りの方法が考えられる。1つは、既存のデータを置き換える方法。そしてもう1つは、新しい値と古い値をマージする方法である。AtomPubとの互換性を維持するために、Microsoftは、PUTメソッドはデータを置き換えるべきだと決断した。

このことは当然ながら、マージ操作をどう表現すればよいかという問題を残した。この問題の解決策には、MERGEという新しい動詞の導入や、新しいカスタムヘッダーの導入が挙がった。Pablo Castro氏は(リンク・英語)、以下のように説明している。

私たちは、新しいHTTPメソッドの導入というアイデアにあまり乗り気ではありません。とはいえ、特別なヘッダーをつけたPUTのオーバーロードには非常に問題があるように思えます。ヘッダーを介した「マージ」をサポートしないサーバは、PUTをただの「置き換え」のリクエストだと考えるでしょう。そして、その操作はクライアントが期待するものとは異なるものなのです。それ以外にもまずい点があります。たとえばサーバがMERGEリクエストを受け取り、しかしそれを処理できなかった場合は、405レスポンス、つまり「サポートされていないメソッドです」と返されてしまいます。

彼らが検討した別の選択肢には、PATCHメソッドもあった。残念ながら、PATCHの仕様はMicrosoftが必要とする期日までに完成されなかった。そのためMicrosoftは、最終的に仕様に互換性がなくなるかもしれないリスクの伴うPATCHを使うか、非推奨かもしれないことを認めた上でMERGEを使うか、という気の進まない状況に立たされた。1つ目の選択肢はクライアントを壊したり、仕様から外れることになる可能性があるため、結局彼らはMERGEを使うことを選んだ。

 クライアントといえば、.NETクライアントはデフォルトで「マージ」として扱うことを知っておくべきだ。この方法が選ばれた理由は、.NETクライアントが必ずしもサーバにあるすべてのフィールドを知っているわけではなく、またサーバにしてみても、フィールドが意図的に空欄になっているのか、それとも単にクライアントが知らなかったのかを判別する手段がないためである。

また、AJAXクライアントもデフォルトで「マージ」として扱う。そして、AJAXクライアントも.NETクライアントと同様に「置き換え」を優先させるためのオプションパラメータを持っている。

原文はこちらです:http://www.infoq.com/news/2008/06/Merge-Replace-Patch

この記事に星をつける

おすすめ度
スタイル

こんにちは

コメントするには InfoQアカウントの登録 または が必要です。InfoQ に登録するとさまざまなことができます。

アカウント登録をしてInfoQをお楽しみください。

あなたの意見をお聞かせください。

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする
コミュニティコメント

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

ディスカッション

InfoQにログインし新機能を利用する


パスワードを忘れた方はこちらへ

Follow

お気に入りのトピックや著者をフォローする

業界やサイト内で一番重要な見出しを閲覧する

Like

より多いシグナル、より少ないノイズ

お気に入りのトピックと著者を選択して自分のフィードを作る

Notifications

最新情報をすぐ手に入れるようにしよう

通知設定をして、お気に入りコンテンツを見逃さないようにしよう!

BT