1. ホーム
  2. http

[解決済み] HTTPメソッドにおけるidempotencyとは何ですか?

2023-05-24 01:57:18

質問

HTTPのドキュメントを読みましたが、何がどうなっているのか理解できません。 idempotency . 誰かが助けることができますか?

どのように解決するのですか?

<ブロッククオート

HTTPメソッドにおけるidempotencyとは何ですか?

べき等 は、HTTPメソッドのプロパティです。

リクエストメソッドは べき乗 もし意図された 効果 と同じであれば、そのメソッドによる複数の同一のリクエストは、サーバ上で の効果 と同じです。そして、特筆すべきは、冪等性が 効果 に生み出される リソースの状態 についてではなく、サーバー上の レスポンスステータスコード についてではなく、クライアントが受け取った

これを説明するために DELETE メソッドを考えてみましょう。これはべき乗として定義されています。ここで、クライアントが DELETE リクエストを実行したとします。サーバはリクエストを処理し、リソースは削除され、サーバは 204 . その後、クライアントは同じ DELETE リクエストを繰り返すと、リソースはすでに削除されているので、 サーバは 404 .

クライアントが受け取るステータスコードが異なるにもかかわらず、1つの DELETE リクエストによって生じる効果は、複数の DELETE リクエストは同じ URI への複数の

最後に、idempotent メソッドを持つリクエストは、クライアントがサーバーの応答を読む前に通信障害が発生した場合、自動的に繰り返されることがあります。クライアントは、リクエストを繰り返すことで 同じ意図した効果 になることをクライアントは知っています。

RFC 7231

を見てみましょう。 RFC 7231 を見てみましょう。この文書は HTTP/1.1 プロトコルのセマンティクスとその内容を定義しています。以下の引用をご覧ください (ハイライトは私のものです)。

HTTP メソッドは 安全 :

<ブロッククオート

4.2.1. 安全なメソッド

リクエストメソッドは、定義されたセマンティクスが本質的に読み取り専用である場合、 "safe"とみなされます。

すなわち、クライアントはターゲットリソースに安全なメソッドを適用した結果、オリジンサーバー上でいかなる状態の変化も要求せず、またそれを期待しません。[...]

この安全なメソッドの定義は、潜在的に有害である、完全に読み取り専用ではない、または安全なメソッドを呼び出している間に副作用を引き起こすような動作を含む実装を妨げるものではありません。 しかし、重要なことは、クライアントがそのような追加の動作を要求しておらず、それに対して責任を負うことができないということです。[...]

この仕様で定義されているリクエストメソッドのうち GET , HEAD , OPTIONS そして TRACE メソッドは安全であると定義されています。[...]

そして/または べき乗 :

4.2.2. べき乗のメソッド

リクエストメソッドは、そのメソッドによる複数の同一のリクエストのサーバに対する効果が、単一のリクエストに対する効果と同じであれば、quot;idempotent" とみなされます。 . この仕様で定義されているリクエストメソッドのうち PUT , DELETE といった安全なリクエストメソッドはべき乗である。[...]

safe の定義と同様に、idempotent 属性はユーザーによってリクエストされたものだけに適用されます。サーバーは各リクエストを別々に記録したり、改訂管理履歴を保持したり、各 idempotent リクエストに対して他の非 idempotent 副作用を実装する自由を持っています。[...]

まとめると、HTTP メソッドは以下のように分類されます。 に続く :

+---------+------+------------+
| Method  | Safe | Idempotent |
+---------+------+------------+
| CONNECT | no   | no         |
| DELETE  | no   | yes        |
| GET     | yes  | yes        |
| HEAD    | yes  | yes        |
| OPTIONS | yes  | yes        |
| POST    | no   | no         |
| PUT     | no   | yes        |
| TRACE   | yes  | yes        |
+---------+------+------------+  

RFC 5789

RFC 5789 が定義している PATCH メソッドがあり、これは 安全でもなければべき乗でもない . しかし、衝突を防ぐために PATCH のリクエストは、以下に引用するように、べき乗となるように発行することができます。

<ブロッククオート

A PATCH リクエストはべき乗となるように発行することができ、これは二つの PATCH リクエストの衝突を防ぐことができます。複数の PATCH リクエストの衝突は PUT コリジョンよりも危険かもしれません。なぜなら、パッチフォーマットの中には既知のベースポイントから動作する必要があり、そうでなければリソースを破壊してしまうものがあるからです。 この種のパッチアプリケーションを使用するクライアントは、クライアントが最後にリソースにアクセスした後にリソースが更新されていた場合、リクエストが失敗するような条件付きリクエストを使用すべきです(SHOULD)。 例えば、クライアントは強い ETag の中に If-Match ヘッダを PATCH リクエストの