REST APIは、後ろのデータを保護する必要がありますか？

Question

大量のデータを削除する可能性のあるDELETEクエリでは、REST APIが盲目的に進んでいるか、警告を出して確認を求められるでしょうか？

私は、リレーショナルDBに格納された複雑なデータの操作を抽象化するAPIを構築しています。他のアイテムによって参照されているアイテムを削除すると、それらを論理的に削除してからカスケードする必要があります。

単純な例は、3つの「ツリー/ブランチ/リーフ」テーブルのセットです。リーフ・ローはブランチのIDへの外部キーを持ち、ブランチ・ローは同様にツリーIDを含みます。 APIは任意のレベルでDELETEを有効にしますが、ツリー項目を削除すると、その項目を直接的または間接的に参照するすべてのブランチとリーフが削除されます。

だから、ツリーのためのDELETEクエリに、APIができます

• ちょうどあなたが依存するすべての項目を削除する必要がありますように、すべてのカスケード削除
• は、それが整合性を破るだろうという理由で拒否遵守してみませんか手動で最初に（実際には実用的でない）
• 何も削除せずに「これは1つのツリー、31のブランチと987のリーフを削除します。確認してください。確認はURL（/ force）の追加ヘッダーやサフィックスの形を取ることができますが、どちらもRESTではないので、クライアントの作成時に直接このようなことを直接バイパスすることがあります（delete + confirmクエリのみが実際に送られます）。私はまた、そのような返事のHTTPコードをためらっています。

私は、APIがシンプルに保たれていて、かつての保護がクライアントにあるべきだと思う傾向がありますが、外部の知恵に感謝します。

Answer 1

これらの質問の通常通り、答えは本当に「それは依存しています」。あなたが「CONFIRM」大きな欠失を有するのルートを行くならば個人的に、私の代わりになります

1. はdepthまたはcascadingヘッダを追加します。代わりに、あなたは本当にこれが欲しいのですか？開発者に深い削除をしたいことを確認するように依頼してください。 Depthは標準ヘッダーですが、WebDAV仕様に含まれています。 Cascadingではないので、それはよいアイデア=と感じるかどうかに応じて、X-という接頭辞が付く可能性があります）。
2. このヘッダーが指定されていない場合は、409と応答してください。これがWebDAVのやり方であり、ここでは多くの意味があります。

しかし、私の観点からは、私はむしろ「削除しない」オプションを持っていると思います。