我希望能够访问可能会应用搜索过滤器（例如代码，用户，群组）的地址簿和日历。
它们不应该是可自动发现的，因为可能有数十亿种组合，但必须与普通客户端兼容（例如iOS / OS X，Windows手机），即应该可以将带过滤器的URL添加到客户端
一个问题似乎是某些客户依赖于发现功能而不是您提供的网址，例如iOS（您尝试通过精确的URL添加一个地址簿，然后添加所有可发现的地址簿）。
另一件事是构建可选的过滤器
使用路径怎么样？
什么是最佳做法？
答案 0 :(得分：1)
日历是只读还是读写？如果它们是只读的，您可以使用网络URL作为日历（也称为“订阅日历”或iCalendar-over-HTTP）。
对于Cal / CardDAV日历，Apple设备（以及大多数其他DAV客户端）配置完整帐户（使用常规帐户发现机制），而不仅仅是“URL”。我认为没有办法解决这个问题。
假设您正在构建提供注册表/搜索引擎的Web服务，或者是此类日历或地址数据的聚合器，则此服务可以提供Cal / CardDAV帐户（实现发现）。
在您的网络服务上，您将有两个选择：
对于联系人，您只能选择1.作为额外的复杂功能，您可能希望将存储的查询公开为vCard组而不是CardDAV集合。这是因为某些客户端（即某些MacOS联系人应用程序）仅支持一个CardDAV集合（并且仅使用组来构建数据）。
示例：假设您发明了一项名为“Caloogle.com”的服务。用户需要获得该服务的一些帐户（可以自动创建等）。用户将CalDAV帐户添加到他的iOS设备（例如，使用预配置的配置文件，这样他就不必输入所有数据），然后连接到Caloogle以将数据提取到iOS EventKit数据库中。 现在，在您的Caloogle应用程序（或网站）中，您可以让用户搜索日历数据。如果用户找到了他喜欢的一组，他会将其作为日历保存到Caloogle中，比如“Dividend Release Dates BP，Apple和AlwaysRightInstitute”。 iOS将最终ping帐户并获取已保存的日历。用户感到惊讶和高兴。
您实际实现Web服务（代理或名称到网址映射）的方式很大程度上取决于数据的来源......
有道理吗？
P.S。：在URL中存储查询时要小心，某些HTTP基础结构组件对URL的长度有限制，高级查询可能会快速溢出。
答案 1 :(得分：0)
与hnh中所说的his answer一样，智能客户端会尝试发现您从URL配置CardDAV或CalDAV时提供的DAV服务，而不是仅使用该URL，因此似乎没有干净的方法来提供由标签，用户，组等过滤的多个虚拟集合。
最简单的解决方案是为每个过滤器URL提供一个虚拟 DAV服务器，并在该过滤器URL的约束范围内进行全面服务发现。
虚拟端点是在URL重写的帮助下提供的，这是常见Web服务器中的一项功能，并且都将指向相同的DAV服务器代码库并为其提供过滤条件。
例如，如果您想要具有标记PR和Spain的项目的CalDAV / CardDAV集合，则可以在https://dav.server/tag:PR/tag:Spain/下公开它们，而标记为{{1的项目可以在China下公开。
请注意，每个URL都提供具有可发现性的完整DAV功能。
由于发现与相应的根https://dav.server/tag:China/和https://dav.server/tag:PR/tag:Spain/相关，因此不会受到干扰。
此外，您可以为一组明确定义的CalDAV / CardDAV集合公开一个简单的URL https://dav.server/tag:China/，例如：用户以某种方式定义的默认日历/地址簿或一些“加书签”的集合，例如， “公关西班牙”。
根据RFC 5785：
，简单网址将提供这些HTTP重定向https://server然后可以通过将主机设置为https://server/.well-known/caldav => https://dav.server/default
https://server/.well-known/carddav => https://dav.server/default
并提供登录凭据来配置iOS客户端和支持知名URI的客户端。
然后他们会尝试通过HTTPS连接，检查众所周知的URI，从而在server发现DAV端点。
那些没有众所周知的URI支持和发现的人需要确切的URL，例如： https://dav.server/default或https://dav.server/default/calendars/jane/main。