On APIs and RSS

Twitter once again made news this week with its 1.1 API terms and in particular the decision to drop support for RSS and ATOM. As with previous policy announcements (see our thoughts from early August here) this has caused unhappiness in various places and worry about further data lock-in by Twitter.

Presumably Twitter has reasons for the switch (it cites complexity of maintenance and their new #hashtag list follow features as reasons) so it is difficult to comment accurately. However, it seems useful to reflect on the differences between RSS and an API – this is something we’re very often asked at 3scale “why do I need an API when I already have RSS”.

The easiest answer to this question is that an API is normally a flexible set of endpoints which can respond to queries with arbitrary data sets, whereas RSS feeds are fixed preprogrammed streams of “latest” content items. This is indeed true – APIs are fundamentally more flexible and can create a far wider set of functionality. They are also typically easier to secure and manage than RSS feeds. However this answer hides some nuance:

  • Many companies actually use highly sophisticated RSS configurations to emulate data services not disimilar to those found in some APIs – such as creating custom feeds for certain customers, multiple feeds with minor variations and (for example) using URL structure effectively as a set of parameters to retrieve the latest feed items for some narrow combination of requirements.

  • RSS is in some sense a specific API in its own right – with specific semantics for calls (the “latest” X items on this topic) and standard formats for the data being returned. This makes the content from this API accessible to many thousands of reader implementations.>

As a result, if the aim is to expose a list of “latest” information, RSS remains a powerful tool to do this – primarily due to all the existing clients out in the world which can consume the resulting feed. However, if what you are trying to achieve is a flexible integration point, then an API is very likely the best way to go. Even if some of the functionality might be achieved by using multiple custom RSS feeds this quickly gets hard to maintain.

Another reason that RSS is somewhat limited today is that there was never any clear very widely supported standard mechanism for authentication. Some readers supported username/password combinations but others did not or stored the credentials in a very insecure way. This problem means that reliably exposing private feeds was difficult since client support was choppy.

Returning to Twitter’s change – clearly it represents a shift towards it’s API which provides some similar features. However it is also a little unfortunate in that the standard RSS access provided a way for many people to access “part of the API” without having to write any code themselves. Certainly such a change has impact on business goals as people will find it more difficult to experience tweets in what is still a tool of choice for them (an RSS Reader). It is likely also bad news for services like Twittertorss.

As a general rule, supporting RSS or not really depends on business goals – doing so is powerful in particular for applications which aim to share out information to a broad range of installed clients. If this “broadcast” element is not appropriate, then an API focused on the business goals you which to achieve may be preferable.