使用网页信息流:不仅仅是 RSS

Farai Gandiya - 2021 年 12 月 16 日

Google Chrome 尝试“关注”网站以及创作者越来越不满社交媒体平台通过算法信息流限制其粉丝的触达范围之际,RSS 信息流重新引起了人们的兴趣,随着我们进入 2022 年,它们将迎来复兴。

这项研究得到 Frontend Masters 的支持,它是 CSS-Tricks 的官方学习合作伙伴。

需要前端开发培训吗?

Frontend Masters 是获取前端开发培训的最佳场所。他们提供有关所有最重要的前端技术的课程。有兴趣全栈发展吗?这是您的最佳选择

您可能在网络上听说过“RSS 已经死了”的传言,但事实是,它们仍然被广泛使用,因为几乎每个播客都使用了一个 RSS 信息流。也许您曾经是 RSS 的粉丝,现在需要重新熟悉它。或者也许您像 CSS-Tricks 的 Chris 一样仍然热爱 RSS。无论如何,RSS 是一种与其他任何网络技术一样的网络技术,而且有一些关于如何创建和管理信息流的最佳实践。

这正是我将在本文中带您逐步完成的内容。让我们讨论一下不同类型的信息流、如何实现它们以及您可以使用哪些策略来充分利用您的信息流内容。

RSS 与 Atom 与 JSON

信不信由你,RSS 只是其他类型 **联合式网页信息流** 中的一种格式。最常见的格式是

  1. RSS
  2. Atom
  3. JSON 信息流

我一直使用 RSS 来表示这些格式,因为它是一个更受欢迎的搜索词,但在本文中,我会将这些技术称为网页信息流,除非我指的是特定的格式。

On Sept 26–Oct 2, 2021, RSS had 37 points, web 6, atom 2 and jsonfeed 0. S
Atom、JSON、RSS 和网页信息流的 Google 趋势。(来源:Google 网络趋势**)**

尽管 Atom、RSS 和 JSON 信息流都实现了相同的功能,但它们之间存在一些差异

  • Atom 和 RSS 基于 XML,而 JSON 信息流基于 JSON。
  • 所有这些格式都可以以某种方式扩展。在 JSON 信息流中,这是通过在信息流对象的任何位置添加一个键以下划线开头的对象来完成的。对于 Atom 和 RSS,您通过在根元素上声明命名空间来完成此操作。一个例子是播客信息流,它声明了 iTunes 播客命名空间,允许使用 <itunes:*> 标签。
  • JSON 信息流是一种较新的信息流格式,这意味着它可能不像 Atom 或 RSS 那样得到广泛支持。但是,如果您有播客,则 **RSS 是必不可少的**。
  • 虽然所有格式都需要为每个条目/项目提供唯一的标识符,但 Atom 更进一步,因为它要求为每个信息流提供唯一的标识符。
  • 所有格式都允许 HTML 标记,尽管它们处理方式不同。JSON 使用包含 JSON 转义 HTML 的 content_html 键。Atom 使用包含 XML 转义 HTML 的 content 标签,其中 type=html。RSS 使用 <description> 标签(或 content 扩展),其中包含 XML 转义 HTML 或在 <![CDATA[]]> 标签中未转义的 HTML。

除了这些之外,它们之间只有细微的差别。您可能认为文件大小可能是潜在的差异,但压缩将它们全部减少到只有几 KB。除非您的应用程序有特定的用例需要特定格式(如播客),否则提供多种格式不会造成任何伤害,但 RSS 和 Atom 的支持度最高。

什么构成了一个“好的”信息流?

让我们来看看一些制作信息流的最佳实践。与网络上的大多数事物一样,我们可以做一些事情来优化我们的工作,以充分利用它。

1. 易于查找

如果您有一个信息流,但没有人知道它,那将毫无用处。使信息流可被发现的一种方法是在您网站的 <head> 中链接它。这样,信息流阅读器就可以爬取并识别出哪些网站提供内容信息流。

以下是一个示例,它展示了三种格式都在文档头部链接起来

<head>
  <link rel="alternate" type="application/rss+xml" href="https://codelab.farai.xyz/index.rss.xml" title="Farai's Codelab's RSS Feed" />
  <link rel="alternate" type="application/feed+json" href="https://codelab.farai.xyz/index.feed.json" title="Farai's Codelab's JSON Feed" />
  <link rel="alternate" type="application/atom+xml" href="https://codelab.farai.xyz/index.atom.xml" title="Farai's Codelab's ATOM Feed" />
  <!-- etc. -->
</head>

是的,您可以同时使用所有三种格式!您可以指定任意数量的链接,尽管一些信息流阅读器可能只识别第一个链接。重要的是,其中一个包括 rel="alternate" 和信息流的 MIME type。还可以选择添加标题,这不会造成任何伤害。

您还可以做些什么来使您的信息流易于查找?宣传它!将信息流的直接链接放置在您网站的醒目位置,人们可以使用这些链接将其复制粘贴到他们的信息流阅读器中。

这就是 CSS Tricks 的做法。 这是该网站 RSS 信息流的链接,它在整个网站的页脚中都可用。一些信息流阅读器也可以识别出这些链接,即使它们位于 <head> 之外。

Screenshot of the CSS-Tricks footer showing a column of links with the heading Follow, and links for social networks, including the site's RSS feed. The background is near black, the headings are orange, and the links are light gray.
哦,您想订阅 CSS-Tricks RSS 信息流吗?请订阅!您的 RSS 信息流与任何社交网络一样值得关注。

至于如何命名信息流本身,只要它可以被发现,名称并不重要。以下是对 各种网站如何命名其信息流 的详细介绍,但我分别将我的信息流命名为 feed.jsonfeed.rss.xmlfeed.atom.xml,分别用于 JSON 信息流、Atom 和 RSS。

2. 利用 HTTP

网络的某些基本功能可以用来使您的信息流变得更好。

例如,请确保压缩您的信息流,因为这将大大减小文件总大小和下载时间。大多数服务器可以使用 gzip、Brotli 或其他压缩引擎为您完成此操作。

同样,支持 ETagsIf-Modified-Since 也是一个好主意,因为它们都允许客户端缓存信息流并告知浏览器在下载之前是否存在更新版本的信息流。与压缩类似,您的服务器也可能处理此操作。

另一个要做的事情是:启用宽松的 CORS。否则,客户端可能会被阻止获取信息流。虽然您应该考虑允许任何旧网站获取您信息流的安全隐患,但对于大多数小型网站和信息流来说,这不太可能成为一个主要问题。这行代码就是您启用 CORS 所需的全部内容

Access-Control-Allow-Origin: *

3. 显示完整内容,而不是摘要

这完全是用户体验方面的问题。您可能以前也遇到过这种情况,您订阅了 RSS 信息流,但您得到的只是文章的第一段或摘要。为什么?传统的观点认为,只提供摘要会鼓励用户点击链接访问您的网站,从而导致更多访问量。更多访问量等于更多眼球,等于更多收入,等等。

我建议避免这种情况,而是允许您的信息流发送每个帖子/条目/项目的全部内容。许多用户更喜欢在信息流阅读器中阅读内容,因为它们强调了可读性。

如果您担心有人会不诚实地抓取您的内容并将其显示在他们自己的网站上,因为您正在提供完整的内容,请让我向您保证:这与网络页面一样容易,就像一个联合供稿。

如果您是依赖展示广告的发布者,并且担心发送完整内容可能会对您的收入产生影响:您仍然可以将静态广告直接添加到您的供稿内容中。此外,一些读者可以解析与供稿条目关联的网页,以便在阅读器中阅读。

Dark UI with blue links and light gray text showing an article from a blog.
N/N Group 文章在 NetNewsWire 阅读器中呈现

但我们不要教条主义,因为在某些情况下摘要是有意义的。一种情况是当供稿包含大量长篇条目时。另一种情况是当您有只能以特定方式查看的丰富内容时(例如播客的节目说明)。在这种情况下,请尝试制作一个好的摘要。一个例子是 Nielsen Norman Group 的 RSS,它有一个摘要和一个直到第一个 <h2> 标签的摘录。

如果我决定在我的供稿中只显示摘要,我会确保除了摘要之外,还包括一张图片、内容要点概述和指向规范版本的链接。这需要一些工作,但它让读者了解可以期待什么,不像我看到的一些供稿,它们很尴尬地将内容截断到前几个词。

Showing a post title in white with the published date and time below it in light gray. Below that is an image of a tired looking man with dark slicked back hair holding a 10 of diamonds card. Below that is the first sentence of a post that breaks mid-sentence.
是的?你想完成那句话吗?

4. 它是为 *阅读* 而设计的

在制作内容时,请考虑它如何在网页浏览器之外的地方被看到,在 JavaScript 和 CSS 受到限制的地方。 Sara Soueidan 提供了许多值得关注的技巧和想法。主要思想:**为您的内容提供良好的回退体验。**

这在嵌入元素方面是一个主要问题。虽然一些嵌入在他们的标记中包含回退内容(例如 Twitter 的嵌入推文和 CodePen 的嵌入笔),但其他一些可能没有。某些嵌入(包括发布到 Vimeo 的视频)只能嵌入在某些域中,这意味着这些视频不会显示在供稿阅读器中。因此,您需要提供一种方法来查看它,例如一张图片或指向网页的链接。

显示在 Microsoft Outlook(左)和 NetNewsWire(右)中呈现的同一篇文章。这篇文章包括三个嵌入,一个来自 Twitter,一个来自 YouTube,另一个来自 TinkerCad),每个嵌入都包含某种形式的回退内容,以提供更好的阅读体验。

有很多方法可以执行回退。Twitter 的嵌入回退到一个 <blockquote> — 这很有道理,因为推文有点像引用 — 以及指向推文本身的链接,这允许一些不支持嵌入的客户端,如 Outlook,以一种仍然对用户可访问的方式有效地呈现内容。

尽管 NetNewsWire 擅长嵌入,但 YouTube 有时会阻止它播放视频,就像这里一样。因此,嵌入回退到一个指向用户在 YouTube 网站上观看视频的链接。Outlook 不支持 YouTube 嵌入(或任何嵌入),但仍然可以提供指向 YouTube 上视频的描述性链接。

故事的寓意:了解您的读者以及他们如何呈现内容,以便您可以提供最好的回退体验。

注意相对 URL

供稿中的一个大问题是解析图片和链接的相对 URL。根据供稿的规范链接解析可能有效,但如果该链接位于子目录中会发生什么?XML 格式可以使用 xml:base 属性,它定义在解析相对 URL 时使用的基本 URL,但该属性仅受 Atom 支持,并且被大多数阅读器忽略和弃用。

最可靠的解决方案是为条目内容中的每个 hrefsrc 使用绝对 URL。这意味着标记看起来像这样

<p>Read <a href="https://css-tricks.cn/archives/">all our articles</a>.</p>

…而不是这样

<p>Read <a href="/archives/">all our articles</a>.</p>

…也不是这样

<p>Read <a href="archives/">all our articles</a>.</p>

这很难自动完成,特别是对于静态生成的网站。一种方法是在构建管道中编译供稿后,将相对 URL 转换为绝对 URL。另一种方法是操纵静态网站生成器渲染 Markdown 链接和图片的方式,使 URL 成为绝对 URL。我希望更多静态网站生成器允许使用第二种选项,但目前,Hugo 是唯一通过 Markdown 渲染钩子 支持此功能的静态网站生成器。

但是,这条规则有一个例外。那就是脚注。 一些阅读器可以检测脚注 并处理它们。以下是一些在任何支持相对跳转链接的供稿阅读器中都应有效的 HTML 代码

<p>They’d managed to place 27.9MB of images onto the Critical Path. 
Almost 30MB of previously non-render blocking assets had just been 
turned into blocking ones on purpose with no escape hatch. Start 
render time was as high as 27.1s over a cable connection<sup id="fnref:1">
  <a href="#fn:1" class="footnote">1</a></sup>.</p>

<div class="footnotes">
  <ol>
    <li id="fn:1">
     <p>5Mb up, 1Mb down, 28ms RTT. <a href="#fnref:1" class="reversefootnote">↩</a></p>
    </li>
  </ol>
</div>

如何在供稿中处理广告

您不太可能在 RSS 阅读器中获得 JavaScript 支持,这意味着没有连接到广告服务器的广告。换句话说,广告需要 *成为您内容的一部分*,而不是动态注入到位的元素。

Showing an advertisement for anima that displays a brightly colored image, text below the image that says our sponsor, followed by the post title in blue, a blurb from the article content, them a blue learn more link.
Codrops 时事通讯是一个做得很好的例子。时事通讯包括赞助的图片和文字,并明确指出内容是赞助的。

PSA:并非所有内容都需要包含在供稿中

我见过一些供稿,其中发布的每一篇内容都被打包起来,并可追溯到供稿中最早的条目。我还看到很多发布者每天发布数十条条目的供稿。在这两种情况下,我建议限制从过去存档中可以获取的内容量,并考虑使用多个供稿而不是一个供稿。

完美的例子。 查看 MacRumors.com 的供稿,因为它非常活跃,每天都会发布数十篇新文章。你能想象回到该供稿中,比如十年前的文章吗?可能不会。除非供稿是针对播客,并且存储每一集是有意义的,否则尝试限制存储在供稿中的条目数量,因为用户可能更感兴趣的是较新的内容。这减少了带宽并减少了更新时间,尤其重要,因为用户需要刷新许多供稿。

我很想说 10-15 篇文章就足以存储和展示了,但就像很多事情一样,“这取决于”。虽然对于一个每月推送几次新内容的网站来说,存储少量内容是有意义的,但其他更频繁发布内容的网站可能一天就超过了这个数字。因此,真正理想的文章数量将取决于您发布的内容类型(它是及时的还是常青的?)以及您发布的内容的数量和频率(是一天多次发布还是每月发布几次?)。

但我真正想表达的是,您要避免让用户因大量文章而感到不堪重负。避免这种情况的两种方法包括

  • 显示摘要而不是完整内容(参见,之前规则的另一个例外!),以及
  • 过滤内容,以便用户可以从多个供稿中选择特定类型的内容。换句话说,如果您想提供所有帖子(或特定主题上的完整时间线),请考虑为此主题/类别/标签/等等创建一个专用供稿。

我之所以对供稿的大小如此挑剔,是因为 — 像图片、脚本和其他资产一样 — 供稿的数量和大小会影响供稿阅读器的性能。用户订阅的供稿越多,需要从这些供稿中获取的条目越多,就会增加刷新和显示这些内容所需的时间。

移动供稿

就像网站可能会更改域名一样,您可能需要将供稿从当前地址移动到其他地址。这样做并不难,但在移动之前需要考虑一些重要事项。

例如,最好确保供稿的条目具有全局唯一标识符 (GUID)。这对应于供稿中的 RSS 的 guid 以及 Atom 和 JSON 中的 id。GUI 可以防止供稿阅读器获取重复的条目。如果您使用的是静态网站,这一点尤其重要(也是具有挑战性的)。

虽然使用条目的永久链接作为标识符可能很诱人,但请记住,这些链接可能会更改。要创建一个 GUID,我建议您考虑使用 标签 URI。标签 URI 包含

  • 一个权限(即网站的域名)
  • 一个日期(表示标记实体控制与供稿相关的权限名称的时间点)
  • 要获取的特定 URL
  • 一个片段(它可能是子资源或时间戳)
tag:<authority>,<YYYY-MM-DD>:<specific>#<fragment>

<specific> 部分可以是您网站主页 URL 的相对部分(例如 /),而片段可以是内容的发布时间戳。例如,CSS Tricks 上的一篇文章的标签 URI 可能看起来像这样

tag:css-tricks.com,2021-16-11:/#1637082038781

这样,权威日期可以确保即使域名易手也能保证一致性。此外,您可以在静态网站生成器中管理它,因为您可以跟踪域名的变化。

我建议使用标签 URI 方案的最大原因是 Atom 要求提要的 id 采用 URL 格式。虽然 RSS 和 JSON 没有相同的约束,但标签 URI 方案也适用于它们,这意味着我们拥有完全支持。

并且,有了可靠的 ID,提要可以安全地移动,而不会导致提要阅读器拉取重复条目。要移动提要本身,请设置一个指向新位置的 301 重定向,就完成了。

您可能会遇到一种称为 XML 重定向 的技术,其中包含提要新位置的文件被放置在旧位置。虽然这在您无法操纵 HTTP 代码时非常有用,但我找不到任何实现此功能的提要阅读器。

验证提要

提要,就像 HTML 一样,需要有效才能正常工作。验证提要的好处是,您可以确定您的代码没有错误,并且条目可以从您的网站正确地流向提要阅读器。

W3C 的提要验证服务 是 RSS 和 Atom 提要的一个选项。您提供提要的 URL 或粘贴提要的实际代码,您将获得一份完整报告,显示您是否符合所有最佳实践。您可能会收到警告。这是正常的。大多数警告实际上只是一个提醒,可能不会影响提要。

也就是说,在验证提要时,始终有两件事需要解决

  • item 应包含 guid 元素:正如我们所见,唯一标识符可以防止提要阅读器在提要移动时显示两次相同的条目。
  • element 应包含绝对 URL 引用 - 这些对于阅读器来说很难解析,因此尽可能避免使用相对 URL。

JSON 呢?要验证 JSON 提要,请尝试使用 validator.jsonfeed.org 或使用任何 JSON 模式验证器 根据 JSON 提要模式 进行验证。

管理或限制对提要的访问

您知道如何订阅付费播客,然后获得一个包含所有“高级”内容的特殊提要 URL,这些内容是您通过订阅获得的?嗯,这是因为我们可以控制谁能访问特定提要,同时阻止其他人接收内容。

有两种管理提要访问权限的技术

  • HTTP 基本身份验证 需要用户名和密码,这些用户名和密码要么提示用户提供,要么在提要 URL 本身中推断,例如 https://username:[email protected]/path
  • 提供一个标记 作为查询参数,例如 http://domain.com/path?token=xyz

只要 URL 是 HTTPS,它们就具有相同的安全性,因为 URL 路径和密码是加密的。至于在服务器上处理身份验证,这将是一个全新的主题,尽管有一些关于它的文章 在这里 on CSS-Tricksht here on CSS-Tricks.

加入 RSS 俱乐部!

好的,所以 RSS 俱乐部 的第一条规则是

不要谈论它。让人们自己找到它。让它变得有价值。

但我还是要说,因为是 RSS 俱乐部一部分的提要,是定制提要的绝佳例子。这是因为提要条目 _只_ 在这些提要中可用。换句话说,博客文章会发布,但永远不会显示在实际网站上——它们只能通过提要访问。

Dave Rupert 多年前创立了这个俱乐部,它是一个让 RSS 成为小型社区中内容消费的首选方式的好方法。

加入俱乐部意味着拥有一个专门的提要,用于发布只在该提要中可用的帖子。例如,在 WordPress 中,您可以创建一个新的“RSS 俱乐部”类别,并将其 从主帖查询中过滤掉。这样,您就可以提供一个仅包含该类别的提要,或者提供仍然包含该类别的帖子的完整提要。

(对不起,Dave,我泄露了秘密!)

内容之外的 Web 提要

RSS 可以用于比博客文章或文章更多的事情。例如,GitHub 有 Atom 提要 用于问题、提交、拉取请求和发布。

它们也可以用于提供更新。假设您想要一个提要,通知您网站发生更改时。这是一个好主意,对吧?始终了解发生了什么,尤其是当厨房里有不止一位厨师的时候。

您可以构建某种系统,定期轮询您的提要以查看是否有更改,然后触发一个新的提要条目,但这需要大量资源。另一个想法是实现 Webhook,告诉它在哪里查找更改。另一方面,管理和发送通知可能很麻烦,尤其是当您只想要监控内容时。

我认为值得查看一下 WebSub。您作为发布者,告诉一个 hub 该网站已更改,并且 hub 会通知任何已 订阅 该网站 Web 提要的系统。您可以将您的提要发布到现有的 hub——例如谷歌的 PubSubHubbub Hub——然后在您的提要中指定该 hub。 YouTube 已实现此功能。

WebSub 流程图,Julien Genestoux
版权 © 2018 万维网联盟,(MIT、ERCIM、庆应义塾大学、北京航空航天大学)。

示例!

没有一些好的例子,这样的教程算什么?让我们看一下三个现实世界的例子。

1. RSS 播客

您知道 CSS-Tricks 有一个关于网络历史的正在进行的系列的播客吗? 它确实有。 而且,是的,您可以通过 RSS 订阅它。

播客必须使用 RSS,并带有 xmlns:contentxmlns:itunes 扩展,这些扩展是提供有关播客及其剧集的元数据的必要条件。每集的音频文件在附件中指定,以及其 MIME 类型和大小。RSS 仅限于一个附件,但 Atom 和 JSON 都支持多个附件。

这是提要。请注意 iTunes 特定的标签以及为提供更多上下文而提供的其他信息

<rss version="2.0" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:itunes="http://www.itunes.com/dtds/podcast-1.0.dtd">
  <channel>
    <atom:link href="https://adactio.s3.amazonaws.com/audio/narration/web_history/podcast.xml" rel="self" type="application/rss+xml" />
    <title>Web History</title>
    <link>https://css-tricks.cn/category/history/</link>
    <language>en</language>
    <copyright>2020</copyright>
    <description>Written by Jay Hoffmann and narrated by Jeremy Keith.</description>
    <image>
      <url>https://adactio.s3.amazonaws.com/audio/narration/web_history/WebHistoryPodcast.jpg</url>
      <title>Web History</title>
      <link>https://css-tricks.cn/category/history/</link>
    </image>
    <itunes:author>Jay Hoffman</itunes:author>
    <itunes:summary>The history of the web.</itunes:summary>
    <itunes:explicit>no</itunes:explicit>
    <itunes:type>episodic</itunes:type>
    <itunes:owner>
      <itunes:name>Jeremy Keith</itunes:name>
      <itunes:email>[email protected]</itunes:email>
    </itunes:owner>
    <itunes:image href="https://adactio.s3.amazonaws.com/audio/narration/web_history/WebHistoryPodcast.jpg"/>
    <itunes:category text="Technology"></itunes:category>
    <item>
      <title>Chapter 10: Browser Wars</title>
      <description>In June of 1995, representatives from Microsoft arrived at the Netscape offices. The stated goal was to find ways to work together—Netscape as the single dominant force in the browser market and Microsoft as a tech giant just beginning to consider the implications of the Internet. Both groups, however, were suspicious of ulterior motives.</description>
      <pubDate>Mon, 8 Nov 2021 12:00:00 -0000</pubDate>
      <link>https://css-tricks.cn/chapter-10-browser-wars/</link>
      <itunes:title>Chapter 10: Browser Wars</itunes:title>
      <itunes:episode>10</itunes:episode>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:author>Jay Hoffman</itunes:author>
      <itunes:summary>In June of 1995, representatives from Microsoft arrived at the Netscape offices. The stated goal was to find ways to work together—Netscape as the single dominant force in the browser market and Microsoft as a tech giant just beginning to consider the implications of the Internet. Both groups, however, were suspicious of ulterior motives.</itunes:summary>
      <content:encoded>
        <![CDATA[
          <p>In June of 1995, representatives from Microsoft arrived at the Netscape offices. The stated goal was to find ways to work together—Netscape as the single dominant force in the browser market and Microsoft as a tech giant just beginning to consider the implications of the Internet. Both groups, however, were suspicious of ulterior motives.</p>
        ]]>
      </content:encoded>
      <itunes:duration>00:40:40</itunes:duration>
      <guid>https://adactio.s3.amazonaws.com/audio/narration/web_history/Chapter_10_Browser_Wars.mp3</guid>
      <enclosure url="https://adactio.s3.amazonaws.com/audio/narration/web_history/Chapter_10_Browser_Wars.mp3" length="19608877" type="audio/mpeg"/>
    </item>
</channel>
</rss>

2. 用于帖子的 RSS

让我们再次看一下 CSS-Tricks,这次看一下标准的博客文章 RSS 提要的示例。

此特定 RSS 提要的代码比典型的提要更冗长,这是因为 <rss> 标签添加了多个扩展。许多扩展无法访问,但有一些扩展可以处理其他事情,例如 xmlns:wfw 用于评论、xmlns:dc 用于其他元数据,以及 xmlns:sy 用于提要刷新频率的信息。

<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:wfw="http://wellformedweb.org/CommentAPI/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:sy="http://purl.org/rss/1.0/modules/syndication/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:georss="http://www.georss.org/georss" xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#">
  <channel>
    <title>CSS-Tricks</title>
    <atom:link href="https://css-tricks.cn/feed/" rel="self" type="application/rss+xml" />
    <link>https://css-tricks.cn</link>
    <description>Tips, Tricks, and Techniques on using Cascading Style Sheets.</description>
    <lastBuildDate>Fri, 19 Nov 2021 15:13:49 +0000</lastBuildDate>
    <language>en-US</language>
    <sy:updatePeriod>
  hourly  </sy:updatePeriod>
    <sy:updateFrequency>
  1 </sy:updateFrequency>
    <generator>https://wordpress.org/?v=5.8.2</generator>
    <image>
      <url>https://i1.wp.com/css-tricks.com/wp-content/uploads/2021/07/star.png?fit=32%2C32&ssl=1</url>
      <title>CSS-Tricks</title>
      <link>https://css-tricks.cn</link>
      <width>32</width>
      <height>32</height>
    </image>
    <site xmlns="com-wordpress:feed-additions:1">45537868</site>
    <item>
      <title>Parallax Powered by CSS Custom Properties</title>
      <link>https://css-tricks.cn/parallax-powered-by-css-custom-properties/</link>
      <comments>https://css-tricks.cn/parallax-powered-by-css-custom-properties/#respond</comments>
      <dc:creator>
        <![CDATA[Jhey Tompkins]]>
      </dc:creator>
      <pubDate>Fri, 19 Nov 2021 15:13:46 +0000</pubDate>
      <category>
        <![CDATA[Article]]>
      </category>
      <category>
        <![CDATA[animation]]>
      </category>
      <category>
        <![CDATA[custom properties]]>
      </category>
      <category>
        <![CDATA[GSAP]]>
      </category>
      <guid isPermaLink="false">https://css-tricks.cn/?p=357192</guid>
      <description>
        <![CDATA[
]]>
      </content:encoded>
      <wfw:commentRss>https://css-tricks.cn/parallax-powered-by-css-custom-properties/feed/</wfw:commentRss>
      <slash:comments>0</slash:comments>

      <post-id xmlns="com-wordpress:feed-additions:1">357192</post-id>
    </item>
  </channel>
</rss>

3. JSON Feed

这实际上是我的个人 Feed,我碰巧使用 JSON 来实现它。它非常基础,比其他示例更简洁,因为据我所知,没有像我们在示例 2 中看到的 RSS 扩展那样的 JSON 扩展。

我发现 JSON 更易于阅读和理解,只需要一个包含 Feed 数据的对象,而不用编写整个模板。

{
  "author": {
    "name": "Farai Gandiya"
  },
  "feed_url": "https://codelab.farai.xyz/feed.json",
  "home_page_url": "https://codelab.farai.xyz/",
  "icon": "https://codelab.farai.xyz/fcl-logo.png",
  "items": [
    {
      "content_html": "...",
      "date_modified": "2021-11-13T05:26:07+02:00",
      "date_published": "2021-11-13T05:26:07+02:00",
      "id": "https://codelab.farai.xyz/1636773967",
      "summary": "...",
      "title": "Don't be afraid of the Big Long Page by Amy Hupe, content designer.",
      "url": "https://codelab.farai.xyz/links/long-content-ok/"
    }
  ]
}

Web Feed 在 CMS 和静态网站生成器中的实现

许多 CMS 和静态网站生成器都支持 Web Feed,尽管通常是 RSS,因为它具有最广泛的支持。以下是一些支持 Web Feed 的 CMS。

以下是一些关于向各种静态网站生成器添加 Web Feed(同样主要是 RSS)的资源。

总结

就是这样!我认为这就是您在实现 Web Feed 时需要考虑的几乎所有内容。我们查看了三种不同的格式(RSS、Atom、JSON),涵盖了创建用户友好 Feed 阅读体验的最佳实践,逐步介绍了验证 Feed 的过程,涵盖了对 Feed 进行身份验证的可能性,查看了三个实际的 Feed 示例,并提供了一些跨不同技术的实现方式。

(哦,还有那个关于第一条规则是不能谈论这个规则的事。)

我希望这些指南能够帮助您创建健壮的 Web Feed。如果您在实现 Web Feed 时有任何问题,或者只是想分享您的 RSS Feed,请随时发表评论!