DELETEリクエスト本文のRESTful代替

一方でHTTP 1.1仕様は、ように見えることを可能にメッセージ本文をDELETE要求、それのための定義された意味がないので、サーバはそれを無視すべきであることを示していると思われます。

4.3メッセージ本文

サーバーはどんなリクエストでもメッセージ本文を読んで転送すべきです。リクエストメソッドにエンティティボディの定義されたセマンティクスが含まれていない場合、リクエストを処理するときにメッセージボディを無視する必要があります（SHOULD）。

私はすでに、SOやそれ以降のこのトピックに関するいくつかの関連するディスカッションをレビューしました。

• エンティティボディはHTTP DELETEリクエストで許可されていますか？
• HTTPリクエストメソッドのペイロード
• リクエストボディを含むHTTP GET

ほとんどの議論は、DELETEでメッセージ本文を提供することが許可されている可能性があることに同意しているようですが、一般的には推奨されません。

さらに、さまざまなHTTPクライアントライブラリの傾向に気づきました。DELETEのリクエスト本文をサポートするために、これらのライブラリのログ記録がますます強化されているようです。ほとんどのライブラリは義務的であるようですが、初期の抵抗が少しあることもあります。

私のユースケースでは、DELETEに必要なメタデータを追加する必要があります（たとえば、削除に必要な他のメタデータとともに、削除の「理由」）。私は次のオプションを検討しましたが、HTTP仕様やRESTのベストプラクティス、あるいはその両方と完全に一致しているようには見えません。

• メッセージ本文 -仕様は、DELETEのメッセージ本文には意味論的な値がないことを示しています。HTTPクライアントでは完全にはサポートされていません。標準的な練習ではない
• カスタムHTTPヘッダー -通常、カスタムヘッダーを要求することは標準的な方法に反します。それらの使用は、私のAPIの他の部分と一貫性がなく、いずれもカスタムヘッダーを必要としません。さらに、悪いカスタムヘッダー値を示すために利用できる適切なHTTP応答がありません（おそらく別の質問です）
• 標準HTTPヘッダー -適切な標準ヘッダーはありません
• クエリパラメータ - クエリパラメータを追加すると、削除されるRequest-URIが実際に変更されます。標準的な慣行に反して
• POSTメソッド -（例POST /resourceToDelete { deletemetadata }）POSTは削除のセマンティックオプションではありません。POSTは実際には反対のアクションを表します（つまり、POSTはリソースの下位を作成しますが、リソースを削除する必要があります）。
• 複数のメソッド -DELETE要求を2つの操作（PUT削除メタデータ、次にDELETEなど）に分割すると、アトミック操作が2つに分割され、一貫性のない状態が残る可能性があります。削除理由（およびその他の関連メタデータ）は、リソース表現自体の一部ではありません。

私の最初の好みはおそらくカスタムHTTPヘッダーの次にメッセージ本文を使用することでしょう。ただし、示されているように、これらのアプローチにはいくつかの欠点があります。

DELETEリクエストにそのような必要なメタデータを含めるためのREST / HTTP標準に沿った推奨事項またはベストプラクティスはありますか？私が考慮していない他の選択肢はありますか？

DELETE要求にメッセージ本文を使用しないようにいくつかの推奨事項がありますが、このアプローチは特定のユースケースで適切な場合があります。これは、質問/回答で言及された他のオプションを評価した後、およびサービスのコンシューマーと協力した後に私たちが最終的に使用したアプローチです。

メッセージ本文の使用は理想的ではありませんが、他のオプションのいずれも完全に適合していませんでした。リクエスト本文のDELETEにより、DELETE操作に必要な追加のデータ/メタデータの周りにセマンティクスを簡単かつ明確に追加できました。

私はまだ他の考えや議論にオープンですが、この質問のループを閉じたいと思いました。このトピックに関する皆さんの考えと議論に感謝します！

あなたが望んでいるように見えるのは2つのうちの1つであり、どちらも純粋ではありませんDELETE：

1. 2つの操作があります。1つPUTは削除理由で、次に1 つDELETEがリソースです。削除すると、リソースのコンテンツには誰もアクセスできなくなります。「理由」には、削除されたリソースへのハイパーリンクを含めることはできません。または、
2. あなたは、リソースを変更しようとしているからstate=activeにstate=deleted使用してDELETE方法を。state = deletedのリソースはメインAPIによって無視されますが、管理者またはデータベースアクセス権を持つユーザーは引き続き読み取り可能です。これは許可されDELETEています- リソースのバッキングデータを消去する必要はなく、そのURIで公開されているリソースを削除するだけです。

DELETEリクエストでメッセージ本文を必要とする操作は、最も一般的な、POSTメッセージ本文で必要なすべてのタスクを実行するa、およびに分類できますDELETE。HTTPのセマンティクスを壊す理由はないと思います。

あなたの状況を踏まえて、私は次のいずれかのアプローチをとります。

• PUTまたはPATCHを送信します。削除理由が必要な性質上、削除操作は仮想であると推測しています。したがって、PUT / PATCH操作によるレコードの更新は、それ自体はDELETE操作ではありませんが、有効なアプローチであると思います。
• クエリパラメータを使用する：リソースのURIは変更されていません。これも有効なアプローチだと思います。リンクした質問は、クエリパラメータがない場合に削除を許可しないことについて話していました。あなたの場合、理由がクエリ文字列で指定されていない場合、デフォルトの理由があります。リソースはそのままですresource/:id。リソースのリンクヘッダーrelを使用して、理由ごとに（理由を特定するためのタグを使用して）検出可能にすることができます。
• 理由ごとに別々のエンドポイント使用のようなURLを使用します：resource/:id/canceled。これは実際にRequest-URIを変更し、間違いなくRESTfulではありません。この場合も、リンクヘッダーはこれを発見可能にすることができます。

RESTは法律でもドグマでもないことに注意してください。ガイダンスとしてそれをもっと考えてください。したがって、問題のあるドメインのガイダンスに従わないことが理にかなっている場合は、従わないでください。APIコンシューマに差異が通知されていることを確認してください。

必要なメタデータをURI階層自体の一部として含めることをお勧めします。例（ナイーブ）：

開始日と終了日を本文またはクエリパラメータとして渡す代わりに、日付範囲に基づいてエントリを削除する必要がある場合は、必要な情報をURIの一部として渡すようにURIを構造化します。

例えば

DELETE /entries/range/01012012/31122012 -2012年1月1日から2012年12月31日までのすべてのエントリを削除します

お役に立てれば。