http DELETEを使用したリソースの削除

したがって、HttpのDELETE動詞がべき等であるとすると、次の要求を発行すると、2番目（または3番目、4番目など）に何が起こるでしょうか。

DELETE /person/123

初めてリソースが削除され、204（成功、コンテンツなし）が返されます。以降の呼び出しで204または404（見つかりません）を返す必要がありますか？

ステートレスシステムのHTTPリクエストは独立している必要があるため、1つのリクエストの結果が前のリクエストに依存しないようにする必要があります。2人のユーザーが同じリソースで同時にDELETEを実行した場合にどうなるかを検討します。2番目のリクエストが404を取得することは理にかなっています。1人のユーザーが2つのリクエストを行う場合も同様です。

DELETEが2つの異なる応答を返すことは、あなたにとってべき等ではないと思います。べき等の要求は、必ずしも同じ応答をするのではなく、システムを同じ状態のままにしておくと考えると便利です。したがって、既存のリソースを削除するか、存在しないリソースを削除しようとするかに関係なく、サーバーリソースの状態は同じです。

RESTful Webサービスのクックブックは、このための優れたリソースです。偶然にも、Googleプレビューでは削除に関するページ（11ページ）が表示されています。

DELETEメソッドはべき等です。これは、サーバーが前の要求でリソースを削除した場合でも、サーバーが応答コード200（OK）を返す必要があることを意味します。しかし実際には、べき等操作としてDELETEを実装するには、サーバーがすべての削除されたリソースを追跡する必要があります。それ以外の場合は、404（見つかりません）を返すことがあります。

現在選択されている回答が言っていることに同意します。2番目（および3番目、4番目）のDELETEは404を取得する必要があります。また、回答には143票の賛成票がありますが、反対のコメントには54票の賛成票があるため、コミュニティは約3：1の比率で2つのキャンプに分割されています。この長い議論を解決するためのより多くの情報がここに来ます。

1. まず最初に、「私」、「あなた」、何人かの本の著者の考えから始めましょう。HTTP仕様、つまりRFC 7231から始めましょう。

   • RFC 7231、セクション4.3.5 DELETEは、成功した応答が2xxであることだけを言及しましたが、後続のDELETEが取得するものを呼び出しませんでした。深く掘り下げましょう。
   • RFC 7231、セクション6.5.4 404 Not Foundでは、404応答はリソースが存在しないことを示しています。特定のhttpメソッド（特に、DELETEではない）が呼び出されて別の方法で処理されることがないため、直感的に（そしてDELETE /some/resource/which/does/not/exist当然のことながら）印象を得ることができ、リクエストが404になるはずです。次に、DELETE /some/resource/which/happened/to/be/removed/by/someone/else/five/days/ago404も返す可能性があります。 。では、なぜDELETE /some/resource/i/deleted/five/seconds/ago違う必要があるのでしょうか。「しかし、べき等性はどうですか？！」、私はあなたがそれを叫んでいるのを聞くことができます。少々お待ちください。

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

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

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

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

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

   しかし、RFC 7231によって示唆された意図された方法、つまり後続のDELETEで404を返すことは、最初の問題ではないことを指摘しておきます。3倍以上の開発者がそうすることを選択しましたが、404を処理できないクライアントが原因で重大なインシデントや不満を聞いたことはありますか？おそらく、そうではありません。それは、HTTP DELETE（または、任意のHTTPメソッド）を実装する適切なクライアントは、結果が常に2xxで成功するとは思わないからです。そして、開発者がエラー処理を検討し始めると、404 Not Foundが頭に浮かぶ最初のエラーの1つになります。その時点で、おそらく彼/彼女は、HTTP DELETE操作が404エラーを無視することは意味的に安全であるという結論を導き出すでしょう。そして彼らはそうしました。

問題が解決しました。

最初のDELETE：200または204。

後続のDELETE：200または204。

根拠：DELETEはべき等である必要があります。2回目のDELETEで404を返す場合、応答は成功コードからエラーコードに変わります。クライアントプログラムは、DELETEが失敗したという想定に基づいて、誤ったアクションを実行する場合があります。

例：

• DELETE操作が、クライアントプログラムによって実行されるマルチステップ操作（または「サガ」）の一部であるとします。
• クライアントプログラムは、例えば銀行取引を実行するモバイルアプリであってもよい。
• クライアントプログラムにDELETE操作の自動再試行があるとしましょう（DELETEはべき等であるため、理にかなっています）。
• 最初のDELETEは正常に実行されたが、クライアントプログラムへの途中で200応答が失われたとしましょう。
• クライアントプログラムはDELETEを再試行します。
• 2回目の試行で404が返された場合、クライアントプログラムはこのエラーコードが原因で操作全体をキャンセルすることがあります。
• ただし、最初のDELETEがサーバーで正常に実行されたため、システムが不整合な状態のままになる可能性があります。
• 2回目の試行で200または204が返された場合、クライアントプログラムは期待どおりに続行されます。

このアプローチの使い方を説明するために、PayPalのHTTP APIスタイルガイドには次のガイドラインがあります。

DELETE：このメソッドはステータスコード204を返す必要があります。ほとんどの場合、リクエストはリソースの削除であり、正常に削除されたため、コンテンツを返す必要はありません。

DELETEメソッドもべき等であるため、リソースがすでに削除されていても、204を返す必要があります（SHOULD）。通常、APIコンシューマは、リソースがこの操作の一部として、または以前に削除されたかどうかを気にしません。これは、404ではなく204が返される理由でもあります。