複数のアイテムを削除するRESTフルな方法は何ですか？
私のユースケースは、複数のアイテムを一度に削除できる必要があるバックボーンコレクションを持っている場合です。オプションは次のようです：
すべてのオプションは理想的ではありません。
これはREST規約の灰色の領域のようです。
回答:
/records/1;2;3—したがって、これに対する2xx応答は/records/1;2;3、それらのキャッシュをパージする可能性があります。ないパージ/records/1、/records/2または/records/3; 410の応答/records/1;2;3、またはあなたの観点からは意味のない他のものをプロキシします。records=[1,2,3]までを/delete-requests）し、作成したリソース（で指定されたポーリングLocation、あなたの要求が受け入れられたかどうかを調べるには、応答のヘッダを）拒否され、進行中ですまたは完了しました。これは、長時間実行される操作に役立ちます。別の方法は、リストリソースにリクエストを送信するPATCHことです。/records、その本文には、リソースとそれらのリソースに対して実行するアクションのリストが含まれます（サポートしたい形式で）。これは、要求の応答コードが操作の結果を示すことができる迅速な操作に役立ちます。RESTの制約を守りながらすべてを達成できます。通常の答えは、「問題」をリソースにしてURLを与えることです。
したがって、ここでの削除、リストへの複数のアイテムのPOST、またはリソースのスウォースへの同じ編集などのバッチ操作は、すべて「バッチ操作」リストを作成し、それに新しい操作をPOSTすることで処理できます。
忘れないでください。RESTが問題を解決する唯一の方法ではありません。「RESTは」ただの建築様式であり、あなたはしていない持って、それに付着する（しかし、そうでない場合は、インターネットの特定の利点を失います）。このHTTP APIアーキテクチャのリストを調べて、自分に合ったものを選択することをお勧めします。別のアーキテクチャを選択した場合に何を失うかを自分自身に認識させ、ユースケースに基づいて情報に基づいた決定を下してください。
REST Webサービスでバッチ操作を処理するためのパターンに関するこの質問に対するいくつかの悪い答えはありますか？賛成票が多すぎますが、読むべきです。
DELETE要求を発行すると、要求先とサーバーの間にあるものはすべて、指定されたURLにある単一のリソースが削除されていると見なします。クエリ文字列は、これらのデバイスへのURLの不透明な部分であるため、APIをどのように指定するかは関係ありません。これらはこの知識に関係がないため、異なる動作をすることはできません。
DELETEは禁止されていると私は単に述べます。しないでください。もしそうなら私はあなたの子供たちを食べます。Nom nom nom。
GET /records?filteringCriteria条件に一致するすべてのレコードの配列を返す場合、そのDELETE /records?filteringCriteriaようなレコードをすべて削除できます。
この場合、あなたの質問に対する答えはになりますDELETE /records?id=1&id=2&id=3。
GET /records?id=1&id=2&id=3「ID 1、2、3の3つのレコードを取得する」という意味ではなく、「URLパス/ records？id = 1＆id = 2＆id = 3の単一のリソースを取得する」ことを意味します。中国語の "42"を含む文書、または存在しない可能性があります。
/records?id=1と/records?id=2が送信され、それらの応答は何らかの仲介者（ブラウザやISPなど）によってキャッシュされます。インターネットがあなたのアプリケーションがこれによって何を意味するかを知っていれば、/records?id=1&id=2元のサーバーに問い合わせることなく、すでにある2つの結果を（どういうわけか）マージするだけで、リクエストがキャッシュによって返される可能性があります。しかし、これは不可能です。/records?id=1&id=2無効（リクエストごとに許可されるIDは1つのみ）または完全に異なるもの（カブ）が返される場合があります。
id[]=1&id[]=2またはid=1&id=2クエリ文字列で使用するかどうかにかかわらず、そのクエリ文字列はまさにそれを表します。そして、クエリ文字列がフィルターを表すことは非常に一般的で良い習慣だと思います。また、削除と更新を許可する場合は、GETリクエストをキャッシュしないでください。その場合、クライアントは古い状態を保持します。
Mozilla Storage Service SyncStorage API v1.5は、RESTを使用して複数のレコードを削除する良い方法だと思います。
DELETE https://<endpoint-url>/storage/<collection>DELETE https://<endpoint-url>/storage/<collection>?ids=<ids>ids：提供されたコンマ区切りのリストにあるIDを持つコレクションからBSOを削除します。最大100個のIDを指定できます。
DELETE https://<endpoint-url>/storage/<collection>/<id>http://moz-services-docs.readthedocs.io/en/latest/storage/apis-1.5.html#api-instructions
これはREST規約の灰色の領域のようです。
はい、これまでのところ、バッチ操作（バッチ削除など）について言及しているREST API設計ガイドの1つであるgoogle api設計ガイドに出くわしました。
このガイドでは、コロンを使用してリソースを介して関連付けることができる「カスタム」メソッドの作成について言及しています。たとえばhttps://service.name/v1/some/resource/name:customVerb、ユースケースとしてバッチ操作についても明示的に言及しています。
カスタムメソッドは、リソース、コレクション、またはサービスに関連付けることができます。任意の要求を受け取り、任意の応答を返す可能性があり、ストリーミング要求と応答もサポートしています。[...]カスタムメソッドは最も柔軟なセマンティクスを持っているため、HTTP POST動詞を使用する必要があります[...]パフォーマンスが重要なメソッドの場合、カスタムバッチメソッドを提供してリクエストごとのオーバーヘッドを減らすと役立つ場合があります。
したがって、GoogleのAPIガイドに従って、次のことを実行できます。
POST /api/path/to/your/collection:batchDelete...コレクションリソースのアイテムの束を削除します。
If the HTTP verb used for the custom method does not accept an HTTP request body (GET, DELETE), the HTTP configuration of such method must not use the body clause at all,がカスタムメソッドの章で言ったことは興味深いです。ただし、 GET accounts.locations.batchGetAPIはボディ付きのGETメソッドです。それは奇妙です。developers.google.com/my-business/reference/rest/v4/...
POSThttpメソッドが使用されており、カスタムメソッドのみが指定されていbatchGetます。私はグーグルがそれを（a）すべてのカスタムメソッドが必要であるというルールを守るPOST（私の答えを参照）、そして（b）人々がボディに「フィルター」を簡単に置くことができるようにして、あなたがする必要がないようにするのだと思いますクエリ文字列と同様に、フィルターをエスケープまたはエンコードします。もちろん、欠点は、これが実際にはもうキャッシュできないことです...
https://service.name/v1/some/resource/name:customVerb定義上、RESTfulではありません。
たとえばPUT ~/people/123/shoes、本体がコレクション全体の表現である場合など、コレクションの大規模な置き換えを許可しました。
これは、クライアントがアイテムを確認し、一部をプルーニングして他の一部を追加し、サーバーを更新する必要があるアイテムの小さな子コレクションに対して機能します。空のコレクションをPUTして、すべてを削除できます。
これはGET ~/people/123/shoes/9、PUTが削除してもキャッシュに残っていることを意味しますが、これは単なるキャッシュの問題であり、他の誰かが靴を削除した場合に問題になります。
データ/システムAPIは、有効期限ではなく常にETagを使用するため、リクエストごとにサーバーがヒットし、データを変更するには正しいバージョン/同時実行ヘッダーが必要です。読み取り専用で、ビュー/レポートに調整されたAPIの場合、有効期限を使用して、オリジンへのヒットを減らします。たとえば、リーダーボードは10分間有効です。
のようなはるかに大きなコレクションの場合~/people、私は複数の削除を必要としない傾向があり、ユースケースは自然に発生しない傾向があるため、単一のDELETEは正常に機能します。
将来的には、REST APIの構築や、監査などの同じ問題や要件に当てはまった経験から、GET動詞とPOST動詞のみを使用し、イベントに関する設計（例：POST a change of addressイベント）を使用する傾向がありますが、独自の一連の問題が付属します:)
また、厳密な「Fielding zealot」REST API設計を望まず、生産性とキャッシュ階層化の理由。