2

次のようにJSONにシリアル化するオブジェクトがあると想像してみましょう。

{ "Name" : "Mike",
  "Status" : "Too cool for school",
  "Looks" : "Devilishly good"}

ここで、このオブジェクトを編集するhttp://absoluteTruth.foo/ {id}（PUT）URIがあると想像してください。次の内容を含むメッセージ本文で呼び出す場合：

{"Name" : "Michael"}

（おそらく）他の2つの値を変更しようとする要求に直面した場合のべき等の要求は何ですか？一方では、上記のPUTリクエストにより、次のようにシリアル化されるオブジェクトが生成されるはずです。

{ "Name" : "Michael",
  "Status" : null,
  "Looks" : null}

そうすれば、他の誰かが何をしても、私のPUT操作は常に同じ出力になります。残念ながら、これにより、エンドユーザーは、GETを実行し、受信したデータを変更して、返送する必要があります。（Rich Hickeyは、さまざまなフィールドの更新を完了したことを警告する場合があります。）一方、次の結果になる可能性があることがわかります。

{ "Name" : "Michael",
  "Status" : "Too cool for school",
  "Looks" : "Devilishly good"}

「Status」と「Looks」の値の変更は、「Name」パラメーターのみを指定して呼び出された場合のPUTの副作用には含まれないと言えます。ただし、その後のhttp://absolutetruth.foo/ {id}（PUT）の呼び出しから返される内容は、たとえば、誰かがMichael nee'Mikeの見た目をさらに高く評価するために立ち寄った場合、時々変わる可能性があります。

これはそうではないが、私は恐ろしい質問だと思うが、2616を含む私が読んださまざまなRFCは、その点で不明確である。{"Name"： "Michael"}を使用したPUTtingは、他のすべての値を平坦化するのではなく、そのままにしておけば十分にべき等であると考える傾向があります。信頼できる情報源で決定的な答えを持っている人はいますか？

4

1 に答える 1

0

HTTP 1.1 では、次のように指定されています。

The PUT method requests that the enclosed entity be stored under the supplied 
Request-URI. If the Request-URI refers to an already existing resource, the 
enclosed entity SHOULD be considered as a modified version of the one residing 
on the origin server.

これは、送信する本文がリソースの全体表現と見なされるべきであることを意味します。PUT冪等性はその結果です。

PUT {"Name" : "Michael"}オンにする/barと、リソースは他の「フィールド」について言及しなくなります。

特定の 1 つの属性を変更する場合は、 などの他のリソースを定義する必要があります/bar/name。

于 2013-03-24T07:44:25.420 に答える