DELETE 不可の場合の REST HTTP ステータスコード

質問

私の質問は、HTTP ステータスコードに関する非常に一般的なものです。 DELETE がリソース上で不可能な場合（ただし、ユーザーの権利に関するものではない）、HTTPステータスコードについてです。

リソースの種類でRESTful APIがあります。

は、その DELETE メソッドはリソースに対して認可されていますが、いくつかの条件下ではリソースを削除することができません (このリソースにバインドされたデータがある場合)。

この状況でクライアントに返すべき正しい HTTP ステータスコードは何でしょうか？

私が集めた可能性のいくつかと、それが私のケースで不適切と思われる理由は次のとおりです。

• 403 ( 禁止 ) : ユーザーの権限と関係があるようです。
• 405 ( メソッドは許可されていません ) : このタイプのリソースに対して、APIはこのメソッドに応答するように設計されていないようです。
• 409 ( 競合 ) : 適切なように見えますが、クライアントはAPIとの衝突を解決する可能性を持つべきですが、ここではそうではありません。

更新: リソースを削除できないようにするデータバインディングは、REST APIを介して変更することはできません。しかし、リソースの状態を変更する可能性のある他のアプリによって、データが由来するデータベースがアクセスされるため、他の方法でリソースを解放することができます (DB の SQL DELETE は常にそれを行うことができます)。

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

RFCの文言からすると、409が最も適切だと思います。

409 (Conflict) ステータスコードは、リクエストの実行が が原因で完了できなかったことを示します。 の状態との競合により、リクエストを完了できなかったことを示します。 リソース . このコードは、ユーザが が である が競合を解決してリクエストを再送信できるような状況で使われます。 サーバーは は、ユーザーが競合の原因を認識するのに十分な情報を含むペイロードを生成すべきです。 を生成すべきである。

(強調)

質問文の記述を理解した上で、DELETEが許可されない理由は、正確には 対象リソースの現在の状態との衝突です。 . RFCに示されているように、レスポンスペイロードは理由の表示を与えることができ、また 任意で ユーザ は は解決できるかもしれない。APIが衝突解決の可能性を提供しないからといって、409を不適切にするような仕様は見当たりません。