33

PUT がある場所で PATCH が安全でない理由を理解できません。Asoべき等の部分 - リソースのフィールドを更新すると、そのフィールドは更新後に同じ値を返しませんか?

4

4 に答える 4

44

一般に、リソースを変更せずに PATCH リクエストを安全に実行することはできないため、安全ではありません (それが目的です)。

では、なぜPUT に比べてPATCH が冪等でないのでしょうか? 変更をどのように適用するかが重要だからです。nameリソースのプロパティを変更したい場合は{"name": "foo"}、ペイロードのようなものを送信できます。このリクエストを何度実行しても同じ結果が得られるため、実際には冪等になります。リソースname属性は「foo」になりました。

ただし、リソースを変更する方法については、PATCH の方がはるかに一般的です ( JSON パッチの適用方法については、この定義を確認してください)。たとえば、リソースを移動することを意味する場合もあり、次のようになります{ "op": "move", "from": "/a/b/c", "path": "/a/b/d" }。もう一度呼び出すとエラーになるため、この操作は明らかに冪等ではありません。

そのため、ほとんどの PATCH 操作はべき等かもしれませんが、そうでないものもあります。

他の回答に関する 1 つのコメント: 冪等性は、操作を連続して複数回繰り返すことによって定義されます。他の操作がその間または並行して実行された場合に効果が異なるため、何かが冪等ではないと言うことは、有効な引数ではありません (その場合、一般的に冪等な操作はありません)。数学的には、冪等変換とは、適用する頻度に関係なく (何かを 360 度回転させるなど)、同じ結果が得られる変換です。もちろん、間に他の操作を適用すると、2 つの 360 度回転で異なる結果が生じる可能性があります。

于 2018-07-20T11:24:17.123 に答える
-3

まず第一に、PUTどちらも安全ではありません。

安全なメソッドは、リソースを変更しない HTTP メソッドです。たとえば、リソース URL で GET または HEAD を使用しても、リソースは決して変更されません。

リクエスト（その点でPATCHもそうです）はリソースを更新するためPUT、キャッシュできないため、SAFEではありません。

PUTリクエストは冪等ですが、リクエストは冪等でPUTなければなりません。

冪等 HTTP メソッドは、異なる結果なしで何度も呼び出すことができる HTTP メソッドです。メソッドが 1 回だけ呼び出されても、10 回以上呼び出されても問題ありません。結果は同じになるはずです。繰り返しますが、これは結果にのみ適用され、リソース自体には適用されません。これはまだ操作できます (更新タイムスタンプのように、この情報が (現在の) リソース表現で共有されていない場合)。

要求が冪等であるという背景にある考え方PUTは、リソースの更新呼び出しが失敗した場合、クライアントは、望ましくない状態や一貫性のない状態を引き起こすことなく、同じ呼び出しを再度行うことができるということです。PUTrequest は常にGETリソースへのリクエストの前に置く必要があり、その後リソースのみが変更されていない場合にのみ成功する必要があります。詳細については、- 同様の回答の 1 つを参照してください -同時環境での冪等 PUT リクエスト

現在、PATCHリクエストは選択的なフィールドのみを更新することを目的としています。リソース表現を取得することは想定されていません。そのため、request を複数回呼び出すとPATCH、リソースの状態が望ましくない変更になる可能性があります。したがって、そうではありませんIDEMPOTENT。

例:- リソースがありますPerson

リクエスト 1: PATCH /person/1 {'age': 10} - リソースの年齢を 10 に更新します

ここで、他の並列リクエストがリソースの状態を変更したとします。たとえば、

リクエスト 2: PATCH /person/1 {'age': 19} - リソースの年齢を 19 に更新します

ここで、Request 1 を再度送信すると、リソースの経過時間が再び 10 に更新されるため、望ましくない結果が生じます。

etags または If Modified since ヘッダーを使用して、べき等にすることができます。

于 2016-12-30T06:14:31.037 に答える