2

RESTful サービスで JSON を使用しています。実装はこんな感じ。

http://hostname/aに対する GET が返されます

{
    "a": {
        "b": {
            "c1": "data1",
            "c2": "data2" 
        } 
    }
}

http://hostname/a/bに対する GET が返されます

{
    "b": {
        "c1": "data1",
        "c2": "data2" 
    } 
}

http://hostname/aでの POST (および PUT) の正しい動作を知りたかった

{
    "a": {
        "b": {
            "c1": "newdata" 
        } 
    }
}

c1 を値「newdata」で更新するか、リソース b 全体を置き換えて、c1 だけを含める必要があります (つまり、c2 は上書きされ、もう存在しません)。

4

3 に答える 3

2

あなたは、私がここ数年 REST を扱ってきた中で最も議論の多い問題の 1 つに遭遇しました。

単純な答えは次のとおりです
。一般的なコンセンサスは、HTTP PUT メソッドにはセマンティクスが置き換えられているため、c2 は上書きされ、もう存在しないということです。
PATCH メソッドは、人々が部分的な更新に対処できるようにするために最近導入されました。

ここで、シナリオには 2 つの複雑な問題があります。

  1. PUT にセマンティクスを置換する必要があるのはなぜですか? 部分的な更新を行うことの悪影響は何ですか? 本当に説得力のある議論をまだ聞いていません。

実際、HTTP 仕様では、PUT がセマンティクスを置き換えると具体的には述べていませんが、次のように述べています。

PUT メソッドは、囲まれた表現が有効なリクエスト URI に格納されることを要求します。

しかし、それはまた言います

HTTP/1.1 は、PUT メソッドがオリジン サーバーの状態にどのように影響するかを定義していません。

  1. PUT が置換セマンティクスを持っていると仮定すると、サーバーが置換されていない表現に一部のコンテンツを含める可能性があることが認められます。たとえば、表現にリンクが含まれている場合、それらのリンクを含まない表現の PUT を実行しても、それらのリンクは「削除」されません。タイムスタンプ フィールド、または最終変更データについても同じです。永遠の問題は、クライアントによって省略されたときに削除されるコンテンツと、サーバーがそう言ったために残るコンテンツをどのように定義するかということです!

個人的には、「置換」セマンティクスがあまりにも制約的であることがわかったため、PUT を避けました。しかし、最近、 Mike KellyとMike Amundsenによって、PUT は現在私たちが信じているよりも柔軟であると考えられるべきであると確信し始めています。

于 2011-01-12T02:56:12.443 に答える
1

まず第一に、「b」リソースを変更する場合、POST (または PUT) をhttp://hostname/aだけでなくhttp ://hostname/a/bに送信してみませんか? 指摘/リンクする価値のあるものは、RIA の哲学に従ってリソースとして実装する必要があり、独自の URI を持っています。

于 2011-01-12T01:37:48.283 に答える
0

http://hostname/aに PUT すると、キャッシュされたhttp://hostname/a/b のコピーはどうなりますか? それらが同期していないことは、どのくらいの期間許可されますか?

答えが「キャッシュされていない」の場合...?

「階層型システムの主な欠点は、データの処理にオーバーヘッドとレイテンシが追加され、ユーザーが認識するパフォーマンスが低下することです。キャッシュの制約をサポートするネットワークベースのシステムの場合、これは仲介者での共有キャッシュの利点によって相殺できます。 " ――有名な論文ですね。

于 2011-01-12T06:08:35.353 に答える