私は REST に精通しており、POST を使用して DELETE を実行することは REST コンプライアンスから逸脱していることを認識しています。良いルールである正確な理由を指で示すことはできません。
APIにとらわれないツール(たとえば、特定のAPIメソッドを理解するように構成する必要なく、動詞定義に関する与えられた情報に基づいて実装の状態について仮定を行う開発ツール)の実現可能性と関係があるのではないかと思いますdo)または部分的に成功した削除の場合にきめ細かいエラーを返せないことですが、これらは単なる推測であり、この質問の中心ではありません。
Swanliu の回答は、削除のターゲットとしてグループ化構造を表す URL の使用に言及していますが、与えられた例「/users/expired」は、固定された (そしておそらくシステム定義の) グループ化を示唆しています。任意のコレクションのよりユーザー指向のケースでは、達成するためにある時点で列挙が必要です。
サイズ N のグループに対して N 個の DELETE を発行することは、複雑な待ち時間と原子性の欠如の両方のために魅力的ではありませんが、REST DELETE は単一のリソースのみを対象とする場合があります。
Swanliu の応答が示唆するベスト プラクティスは、削除するオブジェクトの新しい包含親になるリソースを作成できる POST 操作を定義することだと思います。POST は本文を返すことができるため、問題のシステムは、この非ドメイン グループ化リソースの一意の識別子を作成してクライアントに返すことができます。クライアントは向きを変えて、それを削除するための 2 番目の要求を発行できます。POST によって作成されたリソースは短命ですが、目的があります。一括削除操作の目的のターゲットであったドメイン オブジェクトに連鎖的に消滅します。
> POST /users/bulktarget/create
> uid=3474&uid=8424&uid=2715&uid=1842&uid=90210&uid=227&uid=66&uid=54&uid=8
> ...
< ...
< 200 OK
< ae8f2b00e
> DELETE /users/bulktarget/ae8f2b00e
> ...
< ...
< 200 OK
確かに、2 つのネットワーク交換は 1 つだけよりも望ましくありませんが、より小さな一括削除は 2 つのオブジェクトであり、対処するために 2 つの DELETE 操作が必要になることを考えると、公平なトレードオフのように思えます。 2 つ目以降のオブジェクトは無料です。