私は自分のプロジェクトにDAOデザインパターンを実装しようとしています。これはデータベースとの通信に最も一般的に使用されていることを理解しています。HTTPとデータベースの両方のDAOパターン
しかし、通常はインターフェイスと実装があるので、これもHTTPにも使用できるとは思えません。つまり、データベースに対するCRUD用のDAO実装と、CRUD APIへのアクセス用の別のDAO実装があります。しかし、このようにも使用されている場合、APIに対する削除権限がない可能性がある問題を解決する一般的な方法は何ですか？
これは正しいのですか、それともこのためのインターフェイスが必要なのですか？それとも、データベースの実装を簡単に変更できるようにするのですか？
DAOパターンは、一般に、さまざまな形式のデータ表現を切り離すために使用されます。たとえば、データベース・スキーマをJavaアプリケーション・ロジックから分離することができます。インタフェース（あなたが議論していると思います）は、通常、Javaロジックの実装とその実装を切り離すために使用されます。これらの2つの形式のデカップリングはまったく異なり、設計をより保守的または表現力豊かにするならば、両方を併用しない理由はありません。たとえJavaコードが一般的な目的（例えば、再利用可能なライブラリの一部）であったとしても、この点については異なる見解があるにしても、インタフェースによる動作を指定することは義務だとは思わない。
具体的な質問について：データを操作するJavaメソッドがあり、それらの操作が失敗する可能性がある場合は、通常は例外がスローされます。 DAOを使用していて、Javaロジックの一部がデータストレージ実装から大きく切り離されている場合、そのロジックは「アクセス拒否」を意味のある概念として認識しないことさえあります。そのような場合は、例外も切り離して、DAOロジックに一般的な「更新に失敗しました」という例外をスローさせる必要があります。その例外は、特定のストレージ実装から呼び出し元に送信された元の例外（「アクセス拒否」）を保持することができます。広範なデカップリングの危険の1つは、エラーの原因からさらに遠ざかるにつれて、エラー処理がますます非特異的になることです。