I am in the process of redesigning my blog. The default WordPress theme is nice and all but Charlie and Catherine have shamed me into doing something less mundane.
One of the things that had bothered me was my blog roll. It was out-of-date because WordPress’s default way of handling links make it pretty painful to import a list of links. Actually the first time is easy and great but every time after that you just want to shoot yourself. The other problem was that the list was long and it messed up the way the page looked.
So I decided to trim the list in the side bar to just people that I know. But declarative living requires that I keep my blogroll public. So I decided to create a blogroll page (you can find the results here).
Being lazy like I am, I refuse to create this page by hand. I noticed that FeedLounge can export my subscriptions as OPML.
Sadly, FeedLounge completely ignores web architecture. For example, the URI used to export a OPML is http://my.feedlounge.com/export/opml which does not point at my subscriptions but rather to some bit of code that can generate a OPML file. This bit of code figures out who’s subscriptions to export based on, I suppose, a cookie, or something. The details do not matter because it is not something that I can reasonably duplicate in my schedulable ruby script. So instead I have to manually download the OPML file, then transform it and then push it to the server. That process does not take very long but is really annoying that I have to do it. One demerit for FeedLounge for forcing me into a manual process that could have been easily avoided.
So why use REST? Because I want to use your application in ways you have not anticipated or haven’t had the time to implement yet.