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つ目は、実装が「統一インターフェース」に違反している可能性があるということです（ロイの論文
「force_delete」を追加することで、すでに適切に定義されている DELETE メソッドに制約が追加されます。この制約は、私たちだけに意味があります。
また、確認ダイアログは実際には UI の問題であり、すべてのクライアントが削除の確認を望むわけではないため、「5.1.2 クライアント サーバー」に違反していると主張することもできます。
誰か提案はありますか?
ベストアンサー1
いいえ、RESTful ではありません。URIforce_deleteに動詞 ( ) を入れる必要がある唯一の理由は、PUT/DELETE メソッドが利用できない環境で GET/POST メソッドをオーバーロードする必要がある場合です。DELETE メソッドの使用から判断すると、これは当てはまりません。
HTTP エラー コードは409/Conflict、RESTful サービスが操作を実行できない原因となる競合が発生しているが、ユーザーが自分で競合を解決できる可能性がある状況で使用する必要があります。削除前の確認 (削除を妨げる実際の競合がない場合) は、API が要求された操作を実行することを妨げるものが何もないため、それ自体は競合ではありません。
Alex が言ったように、これは UI で処理する必要があります。RESTful サービスはリクエストを処理するだけなので、ステートレスである必要があるためです (つまり、リクエストに関するサーバー側の情報を保持して確認に依存してはいけません)。
UI でこれを行う 2 つの例は次のとおりです。
- HTML5以前:* ユーザーにJS確認ダイアログを表示し、ユーザーが確認した場合にのみリクエストを送信します
- HTML5:* アクション DELETE を持つフォームを使用します。フォームには「確認」ボタンと「キャンセル」ボタンのみが含まれます (「確認」は送信ボタンになります)
(*) HTMLバージョン5より前のバージョンではPUTおよびDELETE HTTPメソッドをネイティブにサポートしていませんが、最近のブラウザのほとんどはAJAX呼び出しを介してこれら2つのメソッドを実行できます。このスレッドクロスブラウザサポートの詳細については、こちらをご覧ください。
アップデート （追加調査と議論に基づく）：
サービスがforce_delete=trueフラグの存在を要求するシナリオは、統一インターフェースロイ・フィールディングの論文で定義されているように。また、HTTP RFC、DELETE メソッドは元のサーバー (クライアント) でオーバーライドされる可能性があり、これはターゲット サーバー (サービス) では実行されないことを意味します。
したがって、サービスが DELETE 要求を受信すると、追加の確認を必要とせずにそれを処理する必要があります (サービスが実際に操作を実行するかどうかに関係なく)。