検索フィルター (タグ、ユーザー、グループなど) が適用されているアドレス帳やカレンダーへのアクセスを提供したいと考えています。
何十億もの組み合わせが存在する可能性があるため、自動検出可能であってはなりませんが、一般的なクライアント (iOS / OS X、Windows Phone など) と互換性がある必要があります。つまり、クライアントにフィルター付きの URL を追加できる必要があります。
問題の 1 つは、一部のクライアントが指定した URL ではなく検出機能に依存しているように思われることです (iOS など) (正確な URL で 1 つのアドレス帳を追加しようとすると、代わりに検出可能なすべてのアドレス帳が追加されます)。
もう 1 つのことは、オプションのフィルターを構造化することです。
パスの使用についてはどうですか？
ここでベストプラクティスと見なされるものは何ですか?
カレンダーは読み取り専用ですか、それとも読み書き可能ですか? 読み取り専用の場合は、カレンダーに webcal URL を使用できます (別名「購読済みカレンダー」または iCalendar-over-HTTP)。
Cal/CardDAV カレンダーの場合、Apple デバイス (および他のほとんどの DAV クライアント) は、「URL」だけでなく、(通常のアカウント検出メカニズムを使用して) 完全なアカウントを構成します。これを回避する方法はないと思います。
レジストリ/検索エンジンを提供する、またはそのようなカレンダーや住所データのアグリゲーターである Web サービスを構築していると仮定すると、このサービスは Cal/CardDAV アカウント (検出を実装する) を提供できます。
Web サービスでは、次の 2 つのオプションがあります。
連絡先の場合は、選択肢 1 しかありません。さらに複雑なこととして、保存されたクエリを CardDAV コレクションではなく vCard グループとして公開することもできます。これは、一部のクライアント (つまり、一部の MacOS 連絡先アプリ) が 1 つの CardDAV コレクションのみをサポートするためです (データを構造化するためにグループのみを使用します)。
サンプル: 「Caloogle.com」というサービスを発明したとしましょう。ユーザーは、そのサービスでいくつかのアカウントを取得する必要があります (自動作成などの可能性があります)。ユーザーは自分の iOS デバイスに CalDAV アカウントを追加し (たとえば、すべてのデータを入力する必要がないように、あらかじめ構成されたプロファイルを使用します)、Caloogle に接続してデータを iOS EventKit データベースにフェッチします。ここで、Caloogle アプリ (または Web サイト) で、ユーザーがカレンダー データを検索できるようにします。ユーザーが気に入ったセットを見つけたら、それをカレンダーとして Caloogle に保存します。iOS は最終的にアカウントに ping を実行し、保存されたカレンダーを取得します。ユーザーは驚き、喜んでいます。
Web サービス (プロキシまたは名前から URL へのマップ) を実際にどのように実装するかは、データの取得元に大きく依存します...
理にかなっていますか？
PS: URL にクエリを格納するときは注意してください。一部の HTTP インフラストラクチャ コンポーネントには URL の長さに制限があり、高度なクエリはこれをすぐにオーバーフローさせる可能性があります。