REST DELETEは本当にべき等ですか？

DELETEはべき等であることになっています。

私が削除した場合http://example.com/account/123アカウントを削除しようとしています。

もう一度実行すると、アカウントが存在しないため、404が期待されますか？存在しないアカウントを削除しようとするとどうなりますか？

べき等は、リクエストが完了した後のシステムの状態を指します

すべての場合（エラーの問題は別として、以下を参照）、アカウントは存在しません。

ここから

「メソッドは、「べき等」のプロパティを持つこともできます（エラーまたは期限切れの問題は別として）N> 0の同一リクエストの副作用は、単一リクエストの場合と同じです。メソッドGET、HEAD、PUT、DELETEは、このプロパティ。また、メソッドOPTIONSおよびTRACEには副作用がないため、本質的にべき等です。

N> 0の副作用 がある重要なビット同一のリクエストは、単一のリクエストの場合と同じです。

ステータスコードが異なることを期待するのは正しいことですが、これはべき等のコアコンセプトには影響しません。サーバーの状態をさらに変更することなく、リクエストを複数回送信できます。

べき等は、リクエストの効果に関するものであり、取得する応答コードに関するものではありません。

http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.1.2は言う：

メソッドは、（エラーまたは期限切れの問題は別として）N> 0の同一のリクエストの副作用が単一のリクエストの場合と同じであるという点で、「べき等」のプロパティを持つこともできます。

異なる応答コードを受け取る場合がありますが、同じリソースにN + 1 DELETE要求を送信した場合の影響は同じであると見なすことができます。

重要な違いは、べき等はすべての影響や応答ではなく、副作用を指すということです。これを行うと、アカウント123がサーバーから削除されます。これが唯一の効果であり、サーバーの状態に変わる唯一の効果です。ここで、同じ要求をもう一度実行すると、サーバーの応答は異なりますが、状態は同じです。DELETE http://example.com/account/123DELETE http://example.com/account/123

DELETEリクエストが別の方法でサーバーの状態を変更することを決定したのとは異なります。別のアカウントを削除したり、エラーログを残したりするなど、アカウントが見つからなかったためです。いや、同じDELETEリクエストを100万回呼び出すことができ、サーバーが最初に呼び出したときと同じ状態にあることを確認できます。

HTTP RFCから：

メソッドは、（エラーまたは期限切れの問題は別として）N> 0の同一リクエストの副作用が単一リクエストの場合と同じであるという点で、「べき等」のプロパティを持つこともできます。

これは「副作用」であり、「応答」ではないことに注意してください。

はい。応答コードに関係なく。

最新のHTTP 1.1 RFCから（強調は私のもの）：

べき等メソッドは区別されます。これは、クライアントがサーバーの応答を読み取る前に通信障害が発生した場合に、要求を自動的に繰り返すことができるためです。たとえば、クライアントがPUTリクエストを送信し、応答が受信される前に基礎となる接続が閉じられた場合、クライアントは新しい接続を確立し、べき等のリクエストを再試行できます。応答は異なる場合がありますが、元の要求が成功した場合でも、要求を繰り返すと同じ効果が得られることがわかっています。

応答が異なる可能性があることを明示的に述べています。さらに重要なのは、それが概念の理由を指摘していることです。アクションがべき等である場合、クライアントはエラーが発生したときにアクションを繰り返すことができ、そうすることによって何もクラッシュしないことを知っています。そうでない場合、クライアントはGET、アクションを安全に繰り返す前に、前のクエリが有効かどうかを確認するために追加のクエリ（おそらく）を行う必要があります。サーバーがそのような保証を行うことができる限り、アクションはべき等です。別のコメントからの引用：

べき等の計算は、システムの堅牢性についてです。障害が発生する可能性があるため（ネットワークの停止など）、障害が検出された場合、どのように回復しますか？最も簡単な回復は、もう一度実行することですが、それは、再び実行することがべき等である場合にのみ機能します。たとえばdiscard(x)、べき等ですがそうでpop()はありません。それはすべてエラー回復に関するものです。

同じことだと思います、404-アカウントは存在しません。

あなたは400-悪い要求を主張することができます。しかし、RESTの意味では、アクションを実行するように要求したオブジェクトは存在しません。これは404に変換されます。

ここで私の別の答えから引用：

歴史的に、1999年に公開されたRFC 2616は、最も参照されているHTTP 1.1仕様でした。残念ながら、べき等に関するその説明は曖昧で、これらすべての議論の余地が残されています。しかし、その仕様はRFC 7231に取って代わられました。RFC7231のセクション4.2.2べき等メソッドから引用すると、次のように強調されます。

要求メソッドは、そのメソッドを使用した複数の同一の要求の意図したEFFECT ON THE SERVERが単一のそのような要求の効果と同じである場合、「べき等」と見なされます。 この仕様で定義されている要求メソッドのうち、PUT、DELETE、および安全な要求メソッド はべき等です。

したがって、それは仕様に書かれており、べき等性はすべてサーバーへの影響に関するものです。最初のDELETEが204を返し、次に後続のDELETEが404を返します。このような異なるステータスコードは、DELETEをべき等ではありません。この引数を使用して後続の204リターンを正当化することは、単に無関係です。

OK、それはべき等についてではありません。しかし、その後の質問として、後続のDELETEで204を使用することを選択した場合はどうなるでしょうか。大丈夫ですか？

良い質問。動機は理解できます。クライアントがエラー処理について心配することなく、意図した結果に到達できるようにするためです。後続のDELETEで204を返すのは、ほとんど無害なサーバー側の「白い嘘」であり、クライアント側はすぐには違いを伝えません。そのため、実際にそれを行っている人々がいて、それはまだ機能しています。"GET / non-exist"は404を返しますが、 "DELETE / non-exist"は204を返すため、そのような嘘は意味的に奇妙であると見なすことができることを覚えておいてください。セクション6.5.4 404 Not Found。

しかし、RFC 7231が示唆する意図された方法、つまり後続のDELETEで404を返すことは、そもそも問題ではありません。さらに多くの開発者がそうすることを選択しました。これはおそらく、HTTP DELETE（または、任意のHTTPメソッド）を実装するクライアントは、結果が常に2xxで成功するとは思わないからです。そして、開発者がエラー処理を検討し始めると、404 Not Foundが頭に浮かぶ最初のエラーの1つになります。その時点で、彼/彼女はうまくいけば、HTTP DELETE操作が404エラーを無視することは意味的に安全であるという結論を導きます。問題が解決しました。