Web standards for content syndication

Published by William Narmontas, , updated .

There is a myriad of W3C standards to syndicate/synchronize content from your server to consumers. Let's find the best way to do that.


Find out which standard is best for your use-case

Can your content be delivered with 1 hour delay, eg a blog?

Pull the data via polling (repeatedly checking at different time intervals). Use the battle-tested Atom and RSS standards. The consumer typically decides how frequently they want to check for new content.

Does your content need to be delivered to a web browser while it is closed?

(Push) Use Push API. Uses service workers.

Does your content need to be delivered to a web browser or a receiver that cannot be reached?

(Pull-Push) Use WebSockets or EventSource.

EventSource (aka Server-Sent-Events) is my favourite approach because it does not need special configuration (unlike WebSockets), is extremely light-weight and is reliable because it supports capturing missed events in case of network error. It is supported by most web browsers and has a great Node.js library.

WebSockets is different, requires more set-up and supports two-way communication as well.

In both cases, an HTTP connection has to be constantly open.

Are your delivery targets pre-defined?

Use HTTP POST for a notification (aka "web hooks"). It is a highly popular approach used by the likes of GitHub to notify of repository updates; however, be mindful of security as without it anybody could trigger an update.

Your targets are self-registering servers.

Use WebSub. This technology is server-to-server enabling immediate updates without having a consistently open connection.