0

我想提供对可能应用了搜索过滤器（例如标签、用户、组）的地址簿和日历的访问。

它们不应该是自动发现的，因为可能有数十亿种组合，但必须与常见的客户端（例如 iOS / OS X、Windows Phone）兼容，即应该可以将带有过滤器的 URL 添加到客户端。

一个问题似乎是某些客户端依赖于发现功能而不是您提供给它们的 URL，例如 iOS（您尝试通过确切的 URL 添加一个地址簿，它会添加所有可发现的地址簿）。

另一件事是构建可选过滤器。
那么使用路径呢？
什么被认为是这里的最佳实践？

4

2 回答 2

1

日历是只读的还是读写的？如果它们是只读的，您可以将 webcal URL 用于日历（又名“订阅日历”或 iCalendar-over-HTTP）。

对于 Cal/CardDAV 日历，Apple 设备（和大多数其他 DAV 客户端）配置完整帐户（使用常规帐户发现机制），而不仅仅是“URL”。我不认为有办法解决这个问题。

假设您正在构建一个提供注册表/搜索引擎的 Web 服务，或者它是此类日历或地址数据的聚合器，那么该服务可以提供 Cal/CardDAV 帐户（实现发现）。

在您的网络服务上，您将有两个选择：

  1. 代理（并可能缓存）远程数据
  2. 创建一个“CalDAV 订阅日历”（一个特殊的 WebDAV 资源，它指向一个 CalDAV 日历（资源类型 { http://calendarserver.org/ns/ }subscribed））。

对于联系人，您只有选择 1。作为一个额外的复杂因素，您可能希望将存储的查询公开为 vCard 组而不是 CardDAV 集合。这是因为某些客户端（即某些 MacOS 联系人应用程序）仅支持一个 CardDAV 集合（并且仅使用组来构造数据）。

示例：假设您发明了一项名为“Caloogle.com”的服务。用户需要在该服务上获得一些帐户（可以自动创建等）。用户将 CalDAV 帐户添加到他的 iOS 设备（例如，使用预配置的配置文件，这样他就不必输入所有数据），然后连接到 Caloogle 以将数据提取到 iOS EventKit 数据库中。现在在您的 Caloogle 应用程序（或网站上）中，您可以让用户搜索日历数据。如果用户找到他喜欢的一组，他会将其作为日历保存到 Caloogle 中，例如“股息发布日期 BP、Apple 和 AlwaysRightInstitute”。iOS 最终会 ping 帐户并获取保存的日历。用户感到惊讶和高兴。

您实际实现 Web 服务的方式（代理或名称到 URL 映射）很大程度上取决于您的数据来自哪里......

说得通？

PS：在 URL 中存储查询时要小心，一些 HTTP 基础架构组件对 URL 的长度有限制，高级查询会很快溢出。

于 2015-04-15T13:10:43.700 回答
0

就像hnh在他的回答中所说的那样，当您从 URL 配置 CardDAV 或 CalDAV 时，智能客户端会尝试发现您提供的 DAV 服务，而不仅仅是使用该 URL，因此似乎没有干净的方法来提供过滤的多个虚拟集合按标签、用户、组等

可行的最简单的解决方案是为每个过滤器 URL 提供一个虚拟DAV 服务器，并在该过滤器 URL 的约束内提供完整的服务发现。

虚拟端点是在 URL 重写的帮助下提供的，这是常见 Web 服务器中的一项功能，并且都将指向相同的 DAV 服务器代码库并为其提供过滤条件。

例如，如果您想要 CalDAV / CardDAV 具有标签的项目集合PR和Spain，您可以在 下公开它们https://dav.server/tag:PR/tag:Spain/，而带有标签的项目China可以在 下公开https://dav.server/tag:China/。

请注意，每个 URL 都提供具有可发现性的完整 DAV 功能。由于发现是相对于各自的根https://dav.server/tag:PR/tag:Spain/和https://dav.server/tag:China/，所以不会有干扰。

https://server此外，您可以为一组明确定义的 CalDAV / CardDAV 集合公开一个简单的 URL ，例如默认日历/地址簿或用户以某种方式定义的某些“书签”集合，例如“PR Spain”。

然后，根据RFC 5785，简单 URL 将提供这些 HTTP 重定向：

https://server/.well-known/caldav    =>    https://dav.server/default
https://server/.well-known/carddav   =>    https://dav.server/default

server然后，只需将主机设置为并提供登录凭据，即可配置 iOS 客户端和支持知名 URI 的客户端。
然后他们会尝试通过 HTTPS 连接，检查众所周知的 URI，从而发现位于https://dav.server/default.

那些没有众所周知的 URI 支持或发现的人将需要确切的 URL，例如https://dav.server/default/calendars/jane/main或https://dav.server/tag:China/calendars/jane/main.

于 2015-04-15T18:43:19.207 回答