RESTを用いた複数レコードの削除
複数の項目を削除するためのREST-fulな方法は何ですか？
私のユースケースは、私は一度に複数のアイテムを削除することができる必要があるBackboneコレクションを持っているということです。オプションは次のようになります。
1.すべてのレコードに対してDELETEリクエストを送信する（数十のアイテムがある可能性がある場合、これは悪いアイデアのように思える）。 2.2. 削除するID'をURLでつないだDELETEを送る（例："/records/1;2;3")。 3.非RESTの方法で、削除対象のID'を含むカスタムJSONオブジェクトを送信する。
どの選択肢も理想的とは言い難い。
これは、RESTの規約のグレーゾーンのような気がします。
80
3
1.1. RESTfulな選択肢として有効ですが、明らかにあなたが説明したような制約があります。 2.これはやめましょう。これは仲介者によって「
/records/1;2;3の（単一の）リソースをDELETEする」という意味に解釈されるでしょう - 従ってこれに対する2xx応答は、仲介者の/records/1;2;3のキャッシュをパージする原因となるかもしれません。 3.3. この選択がベストで、 RESTfullyに行うことができます。もしあなたがAPIを作成していて、リソースの大量変更を許可したい場合、RESTを使ってそれを行うことができますが、正確にどのように行うかは、多くの人にとってすぐに明らかではありません。一つの方法は、 'change request' リソース を作成し (例えば/delete-requestsにrecords=[1,2,3]といったボディを POST して)、作成したリソース (レスポンスのLocationヘッダーで指定) に対して、リクエストが受け入れられたか、拒否されたか、進行中か、完了したかどうかを調べるポーリングを行うことである。これは長時間実行されるオペレーションに便利です。もう一つの方法は、リストリソース** である/recordsにPATCHリクエストを送ることです。その本文には、リソースのリストとそれらのリソースに対して実行するアクションが (サポートしたい任意のフォーマットで) 含まれています。これは、リクエストのレスポンスコードが操作の結果を示すような、素早い操作に便利です。RESTの制約を守りながら、すべてを実現することができます。通常は、"problem"をリソースにし、それにURLを与えることで解決します。
つまり、ここでの削除、リストへの複数のアイテムのPOST、多数のリソースへの同じ編集などのバッチ操作は、すべて "バッチ操作" リストを作成し、新しい操作をそこにPOSTすることで処理することができるのです。
忘れてはならないのは、RESTだけが問題を解決する方法ではないということです。「REST」は単なるアーキテクチャのスタイルであり、それに従わなければならないわけではありません（ただし、従わなければインターネット上のある種の利点を失うことになります）。HTTP API アーキテクチャ](http://algermissen.io/classification_of_http_apis.html)のリストを見て、自分に合ったものを選ぶといいと思います。他のアーキテクチャを選択した場合に何が失われるかを認識し、あなたのユースケースに基づいて情報に基づいた決断をすることです。
この質問に対する https://stackoverflow.com/questions/511281/patterns-for-handling-batch-operations-in-rest-web-services の回答は、あまりに多くのupvoteを獲得していますが、こちらも読んでみてください。
もし
GET /records?filteringCriteriaが条件にマッチするすべてのレコードの配列を返すなら、DELETE /records?filteringCriteriaはそのようなレコードをすべて削除することができます。この場合、質問の答えは「DELETE /records?id=1&id=2&id=3`」となるはずです。
例えば
PUT ~/people/123/shoesのように、ボディがコレクション全体の表現になるような、コレクションの全体的な置き換えができるようにしました。これは、クライアントがアイテムを見直して、一部を切り捨て、他のアイテムを追加して、サーバーを更新したいような、小さなアイテムの子コレクションの場合に有効です。空のコレクションをPUTして、すべてを削除することもできます。
これは
GET ~/people/123/shoes/9が PUT によって削除されてもキャッシュに残ることを意味しますが、これは単なるキャッシュの問題であり、他の誰かが靴を削除したら問題になるでしょう。私のデータ/システムAPIは、有効期限とは対照的に常にETagを使用しているので、リクエストごとにサーバーに負荷がかかります。また、データを変更するために、正しいバージョンと通貨ヘッダを要求します。読み取り専用で、ビューとレポートが一緒になっているAPIでは、オリジンのヒット数を減らすために有効期限を使用します。
大きなコレクション、例えば
~/peopleでは、複数のDELETEは必要ありません。将来的には、REST API を構築して、監査のような同じ問題や要件に直面した経験から、GET と POST の動詞のみを使用し、例えば住所変更イベントを POST するような、イベント周りの設計をしたいと思いますが、それ自体が一連の問題を伴うと思います :)
また、フロントエンド開発者がより厳格なバックエンドAPIを消費する独自のAPIを構築することを許可すると思います。