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.Actually, I noticed this before I switched to
FeedLounge. The ability to export my subscriptions is an absolute
requirement of any aggregator I use. I would not have switched to
FeedLounge if it did not support this.
Initially I though I would write a little ruby script that would pull down my OPML document from FeedLounge and the use ruby-xslt to transform the OPML into and HTML document. This was a nice idea because I could have scheduled it to run every night so that blogroll would always up-to-date.

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.

5 thoughts on “Why REST

  1. Stay tuned for some real APIs coming soon that should give you exactly what you’re looking for. The problem with what you are currently trying to do is that your GET request doesn’t have a n authenticated session associated with it (if it did, it would work), not that we don’t support REST (FeedLounge is ~99% REST).

  2. Well, if it were really RESTful my subscription list would be a
    resource with a real name, say something like
    `http://feedlounge.com/pezra/subscriptions/opml`. If I attempted to
    GET that resource outside of an authenticated session it support HTTP
    based authentication (401 responses, etc). Perhaps the most important
    part of REST is the *uniform* interface it provides. A proprietary
    application specific authentication scheme is not RESTful.

    That being said I understand that providing machine readable data to
    the outside world is not one of FeedLounge‘s
    priorities. It is a user facing aggregator all, and the user
    experience is nice.

  3. > > Sadly, FeedLounge completely ignores web architecture.

    > not that we don’t support REST (FeedLounge is ~99% REST)

    I don’t know if FeedLounge is in fact ~99% REST or not. To be perfectly honest I have not really looked at the information architecture of FeedLounge beyond this the the URLs that show up in the address line (but since FeedLounge is deeply AJAX the URIs in the address line do *not* tell the whole story). So it is possible that this area is an anomily in the RESTfulness of FeedLounge.

  4. Well, if it were really RESTful my subscription list would be a resource with a real name, say something like `http://feedlounge.com/pezra/subscriptions/opml`.

    That is exactly what the API will be providing, among other things. The URL has already been determined and will be:


    Look for this to be available in the next week or two.

    So many features to build, so little time.

Comments are closed.