1. ホーム
  2. http

[解決済み] DELETEリクエストボディのRESTfulな代替案

2022-10-05 02:20:25

質問

とはいえ HTTP 1.1 仕様 を許可しているようです。 のメッセージボディを 削除 リクエストの メッセージの本文は、定義されたセマンティクスがないため、 サーバはこれを無視すべきであると示しているようです。

4.3 メッセージ本体

サーバーはどのようなリクエストでも message-body を読み込んで転送すべきです(SHOULD)。 リクエストメソッドがエンティティボディのための定義されたセマンティクスを含んでいない場合、リクエストを処理する際にメッセージボディは無視されるべきです。 の定義されたセマンティクスを含まない場合、リクエストを処理する際に message-body は無視されるべきです (SHOULD)。

など、SO以降でこのトピックに関するいくつかの関連する議論をすでにレビューしています。

ほとんどの議論では、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 つに分割され、潜在的に矛盾した状態が残ります。削除理由 (およびその他の関連するメタデータ) は、リソース表現自体の一部ではありません。

私の最初の好みは、おそらくメッセージ本文を使用することで、2 番目はカスタム HTTP ヘッダーを使用することです。

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

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

DELETEリクエストにメッセージボディを使用しないことを推奨するものがありますが、このアプローチは特定のユースケースにおいて適切である可能性があります。これは、質問/回答で言及された他の選択肢を評価し、サービスの消費者と協力した後に、私たちが最終的に使用したアプローチです。

メッセージボディの使用は理想的ではありませんが、他の選択肢のどれもが完璧にフィットするものではありませんでした。リクエストボディのDELETEは、DELETE操作に付随して必要とされる追加のデータ/メタデータの周りのセマンティクスを簡単かつ明確に追加することを可能にしました。

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