因此，我一直试图理解WebFinger（RFC7033），偶然发现了Web主机元数据（RFC6415）。据我所知，它们都是RFC，并且以几乎相同的方式解决相同的问题。
因此，如果我想通过其URI查找有关某个人或事物的信息，我可以做两件事：
WebFinger建议我导航到/.well-known/webfinger?resource=...
Host-Meta建议我看一下/.well-known/host-meta，它返回带有<link rel="lrdd" template="http://example.com/lrdd?uri={uri}">之类的JRD或XRD
Webfinger的查询量减少了一次，并鼓励使用JRD。为什么我不能只用一个看起来像host-meta的模板创建一个http://example.com/.well-known/webfinger?resource={uri}并同时做这两种事情（尽管多余）？
我想念的两者之间有什么重要区别吗？我应该优先选择另一个吗？
最佳答案
RFC 7033的作者在这里。
WebFinger进行了几年的开发，在此期间进行了许多更改。 RFC 6415是首次标准化WebFinger概念的尝试，其中包括主机元和LRDD。使用RFC 6415进行发现的过程非常复杂，因为一个事实需要执行两个查询，然后合并每个查询中的信息以创建一组结果的链接关系。此外，已经有一段时间转向JSON了。 WebFinger使用过XML，但是RFC 6415附录A引入了JSON编码。人们希望这是唯一的编码。
与RFC 6415的原始作者以及WebFinger社区的其他人员合作，IETF中的一群人共同努力简化了流程，将内容编码转换为JSON，确保解决方案安全（仅HTTPS），并获得了关于查询用户帐户信息的URI方案（“ acct” URI）的协议。
因此，使用RFC 7033，我们拥有一种安全，简单，单查询的发现机制，其工作原理基本上如下：
$ wfinger [email protected]
这个“ wfinger”客户端将要做的是找到域“ packetizer.com”，然后发出以下查询（使用curl只是为了使示例更清楚）：
$ curl https://packetizer.com/.well-known/webfinger?resource=acct%3Apaulej%40packetizer.com
请注意，任何URI方案仍可与WebFinger一起使用-这个概念没有丢失。因此，按照原始WebFinger的意图，可以查询有关网页（例如www.packetizer.com）或其他类型内容的信息。这是一个例子：
$ curl https://packetizer.com/.well-known/webfinger?resource=http%3A%2F%2Fwww.packetizer.com
这将返回链接关系和有关页面“ http://www.packetizer.com”的其他元数据。