REST、HTTP DELETEおよびパラメーター

HTTP DELETEリクエストにパラメーターを提供することに関してRESTfulでないものはありますか？

私のシナリオでは、「本当に削除してもよろしいですか？」をモデル化しています。シナリオ。場合によっては、リソースの状態は、要求された削除が無効である可能性があることを示唆しています。おそらく、自分で削除の確認が必要ないくつかのシナリオを想像できます。

私たちが採用したソリューションは、削除リクエストにパラメーターを渡して、削除を続行してもよいことを示すことです（ "？force_delete = true"）

例えば

DELETE http://server/resource/id?force_delete=true

私はそれがまだ落ち着いていると信じています：

（a）DELETEのセマンティクスは変更されていません。ユーザーは通常のDELETEリクエストを送信できますが、409で失敗する可能性があり、応答の本文に理由が説明されています。（説明する価値がない理由で）場合によってはユーザーにプロンプ​​トを表示する理由がないため、失敗する可能性があると言います。

（b）Royの論文には、RESTの精神に反することを示唆するものは何もありません。なぜHTTPはRESTの1つの実装にすぎないので、なぜHTTPパラメータを渡すことが重要なのでしょうか。

これがRESTfulでない理由を否定する決定的な声明を誰かが私に指摘できますか？

関連する質問で、ユーザーがforce_deleteを指定しなかった場合、返されます409 Conflict-これが最も適切な応答コードですか？

ファローアップ

さらに調査した結果、DELETEにパラメーターを追加すると、いくつかの原則に違反する可能性があると思います。

1つ目は、実装が「Uniform Interface」に違反している可能性があることです（Royの論文のセクション5.1.5を参照）。

'force_delete'を追加することで、すでに適切に定義されたDELETEメソッドに制約を追加します。この制約は私たちだけに意味があります。

また、確認ダイアログは本当にUIの問題であり、すべてのクライアントが削除の確認を望んでいるわけではないため、「5.1.2クライアントサーバー」に違反していると主張することもできます。

誰か提案？

いいえ、RESTfulではありません。動詞（force_delete）をURIに入れる必要がある唯一の理由は、PUT / DELETEメソッドが利用できない環境でGET / POSTメソッドをオーバーロードする必要がある場合です。DELETEメソッドの使用から判断すると、これは当てはまりません。

HTTPエラーコード409/Conflictは、RESTfulサービスが操作を実行できないような競合がある場合に使用する必要がありますが、ユーザーが自分で競合を解決できる可能性があります。削除前の確認（削除を妨げる実際の競合がない場合）は、APIが要求された操作の実行を妨げるものがないため、それ自体は競合ではありません。

アレックスが言ったように（誰が彼に反対票を投じたのかはわかりませんが、彼は正しいです）、RESTfulサービスはリクエストを処理するだけなのでステートレスである必要があるため、UIで処理する必要があります（つまり、保持による確認に依存してはなりません）リクエストに関するサーバー側の情報）。

UIでこれを行う方法の2つの例は次のとおりです。

• HTML5より前：*ユーザーにJS確認ダイアログを表示し、ユーザーが確認した場合にのみリクエストを送信します
• HTML5：*フォームに「確認」ボタンと「キャンセル」ボタンのみが含まれるアクションDELETEのあるフォームを使用します（「確認」が送信ボタンになります）

（*）5より前のHTMLバージョンは、PUTおよびDELETE HTTPメソッドをネイティブでサポートしていないことに注意してください。ただし、最近のほとんどのブラウザーは、AJAX呼び出しを介してこれら2つのメソッドを実行できます。参照してください。このスレッドのクロスブラウザのサポートの詳細については、を。

更新 （追加の調査とディスカッションに基づく）：

サービスがforce_delete=trueフラグの存在を必要とするシナリオは、Roy Fieldingの論文で定義されている統一インターフェースに違反しています。また、HTTP RFCに従って、DELETEメソッドはオリジンサーバー（クライアント）でオーバーライドされる場合があり、これはターゲットサーバー（サービス）では行われないことを意味します。

したがって、サービスがDELETE要求を受信すると、追加の確認を必要とせずにそれを処理する必要があります（サービスが実際に操作を実行するかどうかに関係なく）。

これは落ち着きのないことだと思います。残りのサービスは、ユーザーに削除の確認を強制するという要件を処理する必要があるとは思いません。これはUIで処理します。

これがプログラムのAPIである場合、force_delete = trueを指定しても意味がありますか？誰かがこのリソースを削除するスクリプトを書いている場合、force_delete = trueを指定してリソースを実際に削除するように強制しますか？

それは古い質問ですが、ここにいくつかのコメントがあります...

1. SQLでは、DELETEコマンドはパラメーター「CASCADE」を受け入れます。これにより、依存オブジェクトも削除するように指定できます。これは意味のあるDELETEパラメーターの例ですが、「man rm」は他のパラメーターを提供することができます。これらのケースは、パラメータなしでREST / HTTPにどのように実装されますか？
2. @Jan、それは確立された慣習のようです。URLのパス部分がリソースを識別するのに対し、クエリ文字列はそうではありません（少なくとも必ずしもそうではありません）。例は豊富です：同じリソースを取得するが異なる形式で取得する、リソースの特定のフィールドを取得するなど。クエリ文字列をリソース識別子の一部と見なす場合、「同じリソースの異なるビュー」という概念を持つことは不可能です。 HTTPコンテンツネゴシエーションなどのREST以外のメカニズム（これは、多くの理由で望ましくない可能性があります）に頼らないでください。

アレックスの答えに加えて：

http：// server / resource / id？force_delete = trueは、http：// server / resource / idとは異なるリソースを識別することに注意してください。たとえば、/ customers /？status = oldまたは/ customers /を削除するかどうかは、大きな違いです。

ヤン