Linda Rising氏による「誰を信頼しますか？」
Agile2008の3日目、8/6(水)午前中の、Linda Risingによるセッションです。セッションの冒頭、Linda Risingはとてもゆったりとしたきれいな、わかりやすい英語で話し始めました。
News
マージか、置き換えか、パッチか：Astoriaはデータの更新をどう扱うか
作者 Jonathan Allen, 翻訳者 菅野 裕 投稿日 2008年7月3日 午後12時44分
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
No comments
返信