REST は、設計された方法で HTTP を使用することです。RESTful にすることを検討してください (タイトルは REST 設計でした:):
- URL はリソースへのパーマリンクにする必要があります (利点のキャッシュ、エンドポイントの保存/共有など...)
- これらはリソースへのパーマリンクであるため、URL に動詞が含まれていると、パスが間違っていることを示します (フィルターは動詞です)。
- リソースのコレクションは、エンドポイント /foos にすることができます。
- リソースのコレクションをフィルター処理する場合は、?filter= などのクエリ文字列パラメーターや ?ids=1,2,3,4,5 などを検討してください。
- GET はリソースを変更すべきではありません。「クリーンアップ」は何かが削除されることを意味するため、GET を実行するときはリソースの変更に注意してください。REST は、GET がリソースを変更すべきではないと述べています。クリーンアップ リクエストを GET として取得し、t がキャッシュされているため OK を返すキャッシュ サーバーを想像してみてください。キャッシュ サーバーは、POST や DELETE などをキャッシュしないことを認識しています (これが HTTP の設計方法です)。
- 複数の呼び出しを除外しないでください。たとえば、get を実行してクリーンアップするリソースのセットを取得し、その後に多数または 1 つの DELETE 動詞呼び出しを実行してクリーンアップを実行することができます。
- 場合によっては、クリーンアップのように機能するトランザクションや「ジョブ」などの一時的なリソースがあります。クリーンアップするアイテムを含むボディを持つリソースへの POST を除外しないでください。ジョブ ID が返されます。次に、クリーンアップの進行状況またはステータスについてジョブ ID を照会できます。
質問が明確ではないため、正確なガイダンスを提供することは困難ですが、うまくいけば、上記の RESTful 原則のガイダンスと考えが正しい方向に進むことを願っています。正確な呼び出しを明確にする場合は、API をお勧めします。
では、重複した foo をクリーンアップしたいとしましょう。
[GET] /foos/duplicates (または /foos?filter=duplicates)
重複している foo の to を識別するボディを返します。1,2,5 (名前の可能性があります) を返すとしましょう。
次に、次を発行できます。
[削除] /foos 本体は 1、2、5 (または一意の場合は名前) を含む配列です。削除呼び出しは受動的であるため、REST の原則に従って GET 呼び出しがキャッシュされていても問題ありません。
POX や JOSN RPC over http などの REST ルートに行かないことも可能で有効ですが、その時点でそれが REST ではないことに気付きます。それは問題ありませんが、フィールディングの論文で説明されている REST の利点は得られていません。
http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
また、これを読んでください：
http://blog.steveklabnik.com/posts/2011-07-03-nobody-understands-rest-or-http
編集：
サーバーに一連のオブジェクト (永続化されたサーバー側ではない) を送信していることを明確にしたコメントを読んだ後、(サーバー側のヘルパー関数のように) 重複が除外されたサブセットを返します。いくつかのオプションは次のとおりです。
- 可能であれば、クライアント/ブラウザ側でこれを行います-ネットワークの往復を使用して、重複をコレクションから除外するのはなぜですか?
- 何らかの理由で、2 つのアイテムが機能的に同等であることを判断するための特定の知識/データをサーバーだけが持っている場合 (データがまったく同じでなくても)、一意の/フィルター処理されたセットを含む応答本文を使用して、データ セットをサーバーに POST することを検討してください。サーバーがセットを永続化していなくても、「一時的な」オブジェクトまたはセットに分類され、サーバーがそれを変更しています。これは概念的にはサーバー リソースの GET ではなく、キャッシュはそのシナリオでは何のメリットもありません。