一份关于Feed URLs的分析
关于Feed是什么可以点击这里,译者注
我一直对Feed接收数据的模式(如果有的话)很好奇。
- 应该叫什么名字?
- 通过目录约定?
index.xml/feed/index.php
- 按格式?
feed.xmlfeed.atomfeed.rssfeed.jsonfeed.php
- 按内容类型?
posts.rss- `articles
blog.atom
- 通过目录约定?
- 它应该有扩展名吗?
*
/rss/*/rss.xml - 它应该在哪里?
/index.xml/path/to/index.xml
我确定答案是:“看情况”。但这里是否有一个通用的模式,让 HTML 倾向于使用index.html文件的无扩展路径?
以上每个问题都重要吗?鉴于你可以使用 HTML 自动发现您的提要,也许准确的 Feed 并不是那么重要?
这的确有可能,但我不太相信。 URL 设计是每个网站最重要的地方之一——我认为这不仅仅是指向 HTML 资源的 URL 。
无论如何,这些想法一直在我脑海中盘旋。然后有一天,我发现了 simeviads 的 web-dev-feeds,这是一个为 Web 开发人员提供的1000个Feed集合。
我的第一反应是:“我必须解析和分析所有这些 Feed !这肯定会告诉我 Feed 的常见模式!”所以这就是我所做的。下面是我的发现的一些内容。
注意:以下内容可能不是 100% 准确,只是粗略分析。
资源名称
| 名称 | 出现次数 |
|---|---|
feed | 512 |
rss | 154 |
atom | 63 |
index | 62 |
main | 20 |
/feed/-> “feed”/path/to/feed-> “feed”/rss/feed.xml-> “feed”/blog/feed/-> “feed”
看起来“feed”是最受欢迎的,超过了其他前四个选项的总和!
资源位置:根目录还是二级目录
| 位置 | 出现次数 |
|---|---|
根目录 /* | 675 |
二级目录 /**/* | 325 |
/feed.xml大概是整个主机的提要/blog/feed.xml大概是博客的提要,但主机上可能有其他资源,比如/podcasts/feed.xml
鉴于命名资源与其所处位置之间存在这种相互依赖的关系,我不确定这个数据点会对任何特定结论产生多大影响——但我仍然觉得看到它很有趣。
资源扩展
| 扩展 | 出现次数 |
|---|---|
任意扩展 /feed.* | 538 |
不扩展 /feed/ | 462 |
任意扩展 (538)
| 扩展类型 | 出现次数 |
|---|---|
*.xml | 459 |
*.atom | 49 |
*.rss | 20 |
*.php | 5 |
*.json | 4 |
以下是 *.xml 扩展名中的细分类目:
| 文件名称 | 出现次数 |
|---|---|
feed.xml | 213 |
rss.xml | 102 |
atom.xml | 56 |
index.xml | 53 |
blog.xml | 9 |
“RSS 和 Atom 之间到底有什么区别,”您可能会问?老实说,这块我知道的不是很多。这是另一天的博客文章——你可以从 Atom 的原始存在理由 开始了解。
至于第二个最受欢迎的 *.atom 扩展,这里是细分类目:
| 文件名称 | 出现次数 |
|---|---|
main.atom | 19 |
gh-pages.atom | 8 |
releases.atom | 4 |
master.atom | 3 |
main.atom- 最近提交到 w3c 设计原则项目gh-pages.atom- 最近向 Web Incubator 的 background-fetch API 提案的面向公众的网站 提交releases.atom- Babel
无扩展 (462)
| 路径名称 | 出现次数 |
|---|---|
/feed/ | 286 |
/rss/ | 51 |
/default/ | 19 |
/atom/ | 7 |
/blog/ | 6 |
/default/ 名称从何而来?有趣的是,每一次出现的 default 都有一个相同的位置:/feeds/posts/default/。这让我认为这些Feed都是由相同的底层技术发布的。也许是 Wordpress ?不。粗略搜索表明此模式源于 Blogger RSS 提要。
其它信息:域名
| 域名 | 出现次数 |
|---|---|
feedburner.com | 62 |
github.com | 34 |
github.io | 23 |
mozilla.org | 11 |
w3.org | 11 |
结论
在筛选完这些数据并写下这篇文章后,我命名 Feed URL 的新方法可能是这样的:
- 使用
feed作为资源名称 - 使用扩展来提示你需要提供的格式(
*.xml、*.atom、*.json等) - 在资源位置使用名词来暗示和消除内容类型的歧义(如果有必要的话)(
/blog/feed.xml、/podcasts/feed.xml等) - 使用
<link>标签让你的 Feed 自动被人发现
例如,如果您只提供博客文章并且由您的主机推送,这种方法看起来不错:
blog.mysite.com/feed.{rss,atom,json}
然而,如果您正在提供无法通过您的主机名推断出的各种内容类型,可以酱婶操作:
mysite.com/{links,posts,notes,podcasts}/feed.{rss,atom,json}
当然,这一切都取决于您网站的 URL 结构。如有必要,请忽略我的非专家建议。
如果您想查看我是如何解析所有这些提要并得出这些状态的,请查看代码。