web-dev-qa-db-ja.com

RESTを使用して複数のレコードを削除します

複数のアイテムを削除するRESTfulな方法は何ですか？

私のユースケースは、複数のアイテムを一度に削除できるようにする必要があるバックボーンコレクションがあることです。オプションは次のようです：

  1. すべてのレコードに対してDELETEリクエストを送信します（潜在的に数十のアイテムがある場合、これは悪い考えのようです）。
  2. 削除するIDがURLでつながれているDELETEを送信します（つまり、「/ records/1; 2; 3」）。
  3. REST以外の方法で、削除対象としてマークされたIDを含むカスタムJSONオブジェクトを送信します。

すべてのオプションは理想的ではありません。

これは、REST規則の灰色の領域のようです。

apirestbackbone.js
75
Donald Taylor
  1. 実行可能なRESTfulな選択肢ですが、明らかにあなたが説明した制限があります。
  2. これをしないでください。仲介者は、「/records/1;2;3の（単一の）リソースを削除する」という意味として解釈されます。これに対する2xx応答により、/records/1;2;3のキャッシュが消去される場合があります。 notpurge /records/1、/records/2、または/records/3; /records/1;2;3、またはあなたの観点から意味をなさない他の事柄に対する410応答をプロキシします。
  3. この選択は最適であり、RESTfulに実行できます。 APIを作成していて、リソースに大量の変更を許可したい場合、RESTを使用してそれを行うことができますが、多くの人にはすぐにはわかりません。 1つの方法は、「変更要求」リソースを作成することです（たとえば、records=[1,2,3]から/delete-requestsなどの本文をPOSTすることによって）作成されたリソース（応答のLocationヘッダーで指定）をポーリングして、要求が受け入れられたか、拒否されたか、進行中か、完了したかを確認します。これは、長時間実行される操作に役立ちます。別の方法は、リストリソースにPATCHリクエストを送信することです、/records、そのボディにはリソースのリストが含まれますそして、それらのリソースで実行するアクション（サポートしたい任意の形式）。これは、要求の応答コードが操作の結果を示すことができる迅速な操作に役立ちます。

RESTの制約内ですべてを達成することができます。通常、答えは「問題」をリソースにしてURLを与えることです。
したがって、ここでの削除、リストへの複数のアイテムのPOST、またはリソースのswatheへの同じ編集などのバッチ操作はすべて、「バッチ操作」リストを作成し、新しいPOSTそれへの操作。

RESTが問題を解決する唯一の方法ではないことを忘れないでください。 「REST」は単なる建築スタイルであり、あなたはそれに固執することはありません（ただし、そうしないとインターネットの特定の利点を失います）。 HTTP APIアーキテクチャ のこのリストを見て、自分に合ったものを選ぶことをお勧めします。別のアーキテクチャを選択した場合に失うものを自覚し、ユースケースに基づいて情報に基づいた決定を下してください。

REST Webサービスのバッチ操作を処理するためのパターン？ には、この質問に対するいくつかの悪い答えがあります。これは、あまりにも多くの賛成票を持っていますが、読むべきです。

69
Nicholas Shanks

GET /records?filteringCriteriaが基準に一致するすべてのレコードの配列を返す場合、DELETE /records?filteringCriteriaはそのようなレコードをすべて削除できます。

この場合、質問に対する答えはDELETE /records?id=1&id=2&id=3になります。

15
Martin Ždila

Mozilla Storage Service SyncStorage API v1.5は、RESTを使用して複数のレコードを削除する良い方法だと思います。

コレクション全体を削除します。

DELETE https://<endpoint-url>/storage/<collection>

単一の要求でコレクションから複数のBSOを削除します。

DELETE https://<endpoint-url>/storage/<collection>?ids=<ids>

ids：にあるIDを持つコレクションからBSOを削除しますカンマ区切りリストを提供しました。最大100個のIDを提供できます。

指定された場所でBSOを削除します。

DELETE https://<endpoint-url>/storage/<collection>/<id>

http://moz-services-docs.readthedocs.io/en/latest/storage/apis-1.5.html#api-instructions

4
bootsoon

これは、REST規則の灰色の領域のようです。

はい、これまでのところ、バッチ操作（バッチ削除など）に言及しているREST AP​​Iデザインガイドは1つしかありません： google APIデザインガイド 。

このガイド メンション コロンを使用してリソースを介して関連付けることができる「カスタム」メソッドの作成。 https://service.name/v1/some/resource/name:customVerb、また、ユースケースとしてバッチ操作を明示的に言及しています。

カスタムメソッドは、リソース、コレクション、またはサービスに関連付けることができます。任意の要求を受け取り、任意の応答を返すことがあり、ストリーミング要求と応答もサポートします。 [...]カスタムメソッドは、最も柔軟なセマンティクスを備えているため、HTTP POST動詞を使用する必要があります[...]パフォーマンスクリティカルなメソッドの場合、リクエストごとのオーバーヘッドを削減するカスタムバッチメソッド。

したがって、GoogleのAPIガイドに従って次のことができます。

POST /api/path/to/your/collection:batchDelete

...コレクションリソースの多数のアイテムを削除します。

3
B12Toaster

コレクションの大規模な交換を許可しました。 PUT ~/people/123/shoesここで、本文はコレクション全体の表現です。

これは、クライアントがアイテムを確認し、一部を削除し、他の一部を追加してからサーバーを更新する必要がある小さな子アイテムのコレクションに対して機能します。空のコレクションをPUTしてすべてを削除できます。

これは、GET ~/people/123/shoes/9がPUTによって削除されてもキャッシュに残ることを意味しますが、これは単なるキャッシュの問題であり、他の人が靴を削除した場合に問題になります。

私のデータ/システムAPIは、有効期限ではなくETagを常に使用するため、各リクエストでサーバーがヒットし、データを変更するには正しいバージョン/同時実行ヘッダーが必要です。読み取り専用でビュー/レポートに合わせたAPIの場合、有効期限を使用してOriginのヒットを減らします。リーダーボードは10分間有効です。

~/peopleのようなはるかに大きなコレクションの場合、複数の削除を必要としない傾向があり、ユースケースは自然に発生しない傾向があるため、単一のDELETEは正常に機能します。

将来、およびREST AP​​Iを構築し、監査などの同じ問題と要件を経験した経験から、GETおよびPOST動詞のみを使用し、イベントを中心に設計したいと考えています。例えばPOSTアドレス変更イベント。ただし、独自の問題が発生する可能性があります:)

また、フロントエンド開発者がより厳密なバックエンドAPIを使用する独自のAPIを構築できるようにします。これは、厳密な "Fielding zealot" REST AP​​Iが好きではない実用的で有効なクライアント側の理由があることが多いためです生産性とキャッシュレイヤリングの理由によります。

1
Luke Puplett

POST、GET、PUTのようなRESTAPIのDELETE HTTPメソッドで複数のパラメーターを送信したい場合は、これを試してください：

DELETE /app/module/test HTTP/1.1
Host: xxx.xxx.x.xx
ACCESS-TOKEN: xxxxxxxxxxxxxxxxxxxxxxxx
Content-Type: text/plain
Cache-Control: no-cache
Postman-Token: 3eabfb52-fdb2-4b05-aefa-b2fb0c53c247

first_name=name1&last_name=name2&mobile_no=2222222222&[email protected]

で区切られた各値

＆（および署名）

content-Typeはtext/plainORtext あなたの好きなように。

これは、郵便配達員にリクエストを送信する際に表示されます。

そして、私はサーバーからの応答を受け取りました

そして、これらの応答は郵便局でこのように見えたサーバーから来ました。

Array
(
    [first_name] => name1
    [last_name] => name2
    [mobile_no] => 2222222222
    [email_id] => [email protected]
)
0
Ashish Patidar