クラウドベースの基幹業務アプリケーションに取り組んでいます。ユーザーは、ドキュメントやその他の種類のオブジェクトをアプリケーションにアップロードできます。ユーザーはかなりの数のドキュメントをアップロードし、合わせて数百万のドキュメントが保存されています。SQL Server を使用しています。
今日、ユーザーが DocumentSearchQuery エンティティを渡して、要求の並べ替え順序とページング情報と共にキーワードを提供できるようにする、やや安静な API を用意しました。基本的に、実際のドキュメントへの参照のソートされたコレクションである DocumentSearchResult が返されます。
検索 API をドキュメント以外のエンティティ タイプに拡張したいと考えており、そのために OData を使用することを検討しています。しかし、OData を使用すると、いくつかの問題に直面するだろうという印象を受けます。
- ユーザーがクエリできるフィールドに組み込みの制限はありません。つまり、パフォーマンスは、インデックス付きフィールドをクエリするかどうかに依存するか、受信 OData リクエストの独自の解析を実装して、インデックス付きフィールドのみをクエリするようにする必要があります。 . (これはマルチテナント アプリケーションであり、物理ハードウェアを共有しているため、遅いクエリは他の顧客に影響するため、実際には受け入れられません)
- バックエンドでデータにアクセスするために使用するものはすべて、IQueryable をサポートする必要があります。私は現在、これを行う Entity Framework を使用していますが、おそらく将来的には別のものを使用するでしょう。つまり、着信クエリを独自に解析する必要がある可能性が高いということです。
- ユーザーがアクセスできるデータを制限する組み込みのサポートはありません。受信した Odata クエリを検証して、実際にアクセス許可を持つデータにアクセスすることを確認する必要があります。
入ってくる式ツリーを手動で解析して、アクセスできるデータにのみアクセスしようとすることを確認したいとは思いません。これは面倒そうです。
私の質問は次のとおりです。上記を考慮して、顧客がエンティティにアクセスする独自のクライアントを作成するマルチテナント環境で、OData を使用することは適切なプロトコルですか?