Jahed Ahmed

Making Sense of Feed Formats

For years now I've had a /feed.xml path for anyone that wanted to get updates on my website. However, the general term for these feeds is "RSS", even when it's not really RSS. In my case, I was using Atom. I looked at both specs and chose Atom since it seemed simpler to understand. That's when I built a simple plugin to generate Atom feeds on Middleman.

After a while, I saw the need for a JSON feed format. Originally I made my own at /feed.json, since I only intended for me to use it and none of the existing formats seems to be standard.

Now I have two feeds, both generated by my own code. Every few months, I'd usually notice a bug with the Atom feed. Maybe it was the formatting of the post, a regression from changing frameworks or just overlooking a detail in the specification. There came a point where I decided it was becoming too fiddly and started looking into something that can do it all for me.

That's when I found jpmonette/feed. You give it all of the data it needs and it'll generate RSS, Atom and JSON Feed format feeds for you. Unlike a lot of generators, it's popular enough to be reliable. It solves all three of my problems:

So I switched over. However, I didn't add actual RSS format feeds until later when I was doing a server upgrade. I noticed Nginx's default mime-types use .atom and .rss file extensions to correctly assign the Content-Type for both formats. Sure I could override this behaviour but that's just more configuration to maintain. So I decided to split /feed.xml to /feed.atom and /feed.rss. For existing subscribers, I set up a permanent redirect for /feed.xml pointing to /feed.atom. It's a bit of configuration, but hopefully feed readers can treat permanent redirects as a sign to permanently update their feed URLs, then I can remove it. They probably don't, much like bookmarks don't... Oh well. At least everything makes sense now.

Thanks for reading.

Support My Work
Related Tags