2 ways to use Superfeedr

Superfeedr provides a powerful RSS feed API which covers the 2 most important ways to consume RSS feeds: push and pull.

When consuming data from Superfeedr, you can choose between either pulling data from us or waiting for us to push you the data from the RSS feeds.

The pull way

Traditionally, this has been how Google’s Feed API worked (beware, it’s been deprecated). Your application queries our API endpoint, using the retrieve¹: mode with the feed’s URLs and we respond with the feed’s content. It’s simple and has a lot of benefits.

Normalisation

All feeds returned use the same schema, be it ATOM, or most often, JSON. This makes consuming the data in your application a lot easier.

A Single Server

Consuming RSS feeds from many servers means that your application will perform a lot of HTTP requests to each of these servers… and will inevitably have to handle bugs and connectivity issues for each of these servers. Speaking to a single server will reduce the problem to communicating with just us! In practice, we just combine feeds for you.

No backend

The web is built around protocols which require clients and servers. Yet, application servers are often considered liabilities: they’re hard to maintain, cost money and cannot always be trusted. If you pull data from us, you can do it directly from the clients (browsers² or phones), which means that you don’t need to deploy, run and maintain a backend server.

CORS headers

When building a front-end only application which consumes RSS feeds, one of the challenges is to deal with the dreaded Same-Origin Policy which all modern browsers implement. Our API endpoints support CORS headers which means requests coming from 3rd party domains will be served.

The push way

On the other end, if you’re planning on consuming thousands (or more!) RSS feeds from us, a better approach is to use our push API. Rather than constantly asking us for the data you need, you can register endpoints where we will push the content of the RSS feeds as soon as they’ve been updated. For this, we use the PubSubHubbub open protocol.

Realtime

The most obvious benefit form this is that you don’t have to query our API to learn about the latest feed entries in any given feed. We do what it takes to learn about new feed updates and we push the content to your servers immediately. That’s the greatest benefit of webhooks.

Decoupling

Another benefit of using the push architecture is that you decouple your feed collection processes (provided by Superfeedr) from the rest of your application (the core of it and what makes it different). Your customers will never know about Superfeedr or care about how the feed’s content has been collected. It also means that you can easily switch away from Superfeedr if you’re not satisfied with us.

No maintenance required

Finally, since we send you notifications for updates in the feeds we fetch, including errors, using our push based APIs means that you are always in sync with us when it comes to dead feeds, errors, or significant changes. There is no need for periodical checks to identify the broken feeds from the ones which are still active.

Generally, if you’re building a complex application with a backend or if you need to aggregate a large amount of feeds (more than a couple dozens and up to tens of millions), we strongly recommend that you use our PuSH APIs.