Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Most consumers of syndication feeds have the expectation that the feed will contain relatively recent content, with previously published content 'falling off' of the feed. How much content you maintain in the feed is usually based on the type of content you are publishing but as the size of your feed grows it can impact a feed clients ability to retrieve and parse your information.</p> <p>If you truly want to publish a historical feed that is continually added to but never has content items removed, you may want to consider the following options (based on the needs of your consumers):</p> <ol> <li>Implement <a href="http://tools.ietf.org/html/rfc5005" rel="nofollow noreferrer">Feed Paging and Archiving</a>, <a href="http://tools.ietf.org/html/rfc5005#section-3" rel="nofollow noreferrer">per RFC 5005 Section 3</a>, as paged feeds can be useful when the number of entries is very large, infinite, or indeterminate. Clients can "page" through the feed, only accessing a subset of the feed's entries as necessary.</li> <li>Logically segment your content into multiple feeds, and provide <a href="http://www.rssboard.org/rss-autodiscovery" rel="nofollow noreferrer">auto-discovery</a> to the feeds on your website.</li> <li>Implement a REST based service interface that allows consumers to retrieve and filter your content as an Atom or RSS formatted feed, with the default representation using some reasonable defaults.</li> </ol> <p><strong>Option 1</strong> is a reasonable approach only if you know the type of feed clients that will be consuming your feed, as not all feed clients support pagination.</p> <p><strong>Option 2</strong> is the most common one seen on public facing web sites, as most browsers and clients support auto-discovery, and you can provide both a full historical feed and a smaller more recent content feed (or segment in ways that make sense for your content).</p> <p><strong>Option 3</strong> potentially allows you to provide the benefits of both of the first two options, plus you can provide multiple feed formats and rich filtering of your content. It is a very powerful way to expose feed content, but usually is only worth the effort if your consumers indicate a desire for tailoring the feed content they wish to consume.</p> <p>While most rich feed clients will retrieve feed content asynchronously, clients that make synchronous (and potentially frequent) requests for your feed may experience timeout issues as the size of your feed increases.</p> <p>Regardless of what direction you take, consider implementing <a href="http://fishbowl.pastiche.org/2002/10/21/http_conditional_get_for_rss_hackers/" rel="nofollow noreferrer">Conditional GET</a> on your feeds; and understand the potential consumers of your syndicated content in order to choose the strategy that fits best. See <a href="https://stackoverflow.com/questions/12509/why-are-people-still-creating-rss-feeds/20713#20713">this answer</a> when you consider which syndication feed format(s) you want to provide.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload