What if Google Reader had a sucky API…?

I’ve been thinking more about the idea of building a VSTO add-in for Outlook that could synchronize between Attensa for Outlook and Google Reader (I wrote previously about the idea here).

I’ve had a heckuva time trying to figure out how to build Web Services client code into a Windows client application.  There’s a ton of books out there documenting how to build the server side of Web Services; even the books and articles that talk about building Web Services client code, are really talking about consuming Web Services into another server application.  I finally figured out a query or two that gave us some leads, but it’s wasn’t exactly a slam dunk.

I’ve also had more trouble than I expected to figure out what the story is with Google Reader’s API.  Back in 2005 there was an effort by Niall Kennedy to reverse-engineer the then-current Reader API; at the time, the Reader team even commented a couple of times on the imminent release of the API.  Ever since then, there’ve been various inquiries but no further details to let folks know where they stood.  [Well, at least from the SOAP API standpoint.]

I’ve been getting more and more suspicious that Google no longer intends to document and release a SOAP-based API for Google Reader.  I finally became convinced of this when I stumbled on a not-terribly-related article by Scoble, where he caught us up on Google’s inauspicious switch from their original SOAP Search API to an AJAX Search API.

My take: despite some of the comments on Scoble’s article that imply he’s just being paranoid, I happen to think there’s merit to the theory that Google has no interest in developing APIs that don’t further their advertising revenue.  It’s not that I particularly dislike Google (I’m a big fan of many of their services), but after two years’ delay from when the Reader team was about to release their SOAP API anyway, it’s pretty hard to imagine that the great disappearing act is not in some way deliberate.

The fact that they developed and released the Reader AJAX API in less time demonstrates that they’re capable of getting a Reader API out in that timeframe, and the distinct lack of mention of any further API development (either on the Reader group discussion boards or on the Reader team’s blog) pretty much seals the deal for me.

So what’s an in-their-spare-time developer supposed to do at this point?

Google Reader: toss it…

From what I see of the Reader AJAX API documentation, it’s not meant as a full-fidelity API for manipulating the contents of a user’s Reader configuration, article read/unread status or even the list of blogs to which they’re subscribed.  I’m not terribly interested in placing an eight-article list of links (+ Google ads) in a VSTO add-in to Outlook.  Nor am I all that interested in trying to use an undocumented and unsupported (not to mention still-in-flux) SOAP API — it’s enough trouble for me to do something once, let alone every week or month when they decide to rip out something else.  It sure doesn’t help to hear someone who’s been keeping an eye on this space say things like Google is embarking on the “creation of de jure and de facto standards which are pitched as being great for customers but seem suspiciously like attempts at Fire & Motion.

Attensa Online reader: no more

I probably wouldn’t even be going down this road if Attensa had kept up their own online web-based feed server.  However, despite multiple positive reviews and different URLs that used to point to it, it’s gone the way of the dodo bird.  Heck, I’ve even lost access to Attensa’s own corporate feed server (to which they gave me an account last year after all the bug reports I’d sent them).

MyYahoo: no published RSS APIs

Many news reports repeat the “fact” that MyYahoo is one of the most popular online RSS readers on the ‘net.  I dug into its interface, documentation, and searched around Yahoo’s site for a while, but it was so obtuse it was hard to actually find any references to terms like RSS or OPML.  I’ve come to the conclusion that there’s either (a) no official API for MyYahoo feed reading, or (b) it’s just not something Yahoo has invested any effort into.  However, Niall Kennedy has documented some API characteristics, and I stumbled upon Yahoo’s general developer documentation (among which they mention that most APIs use the REST approach).  The Yahoo SDK provides C# & VB.NET samples for Yahoo’s various search properties but nothing more.

NewsGator Online: in a word, wow

According to a trip report from ETech 2006, the Newsgator API “uses standard protocols (SOAP) which can be consumed from any platform” and it “supports granular operations [add feed, mark item read, rename feed, etc]”.  The Newsgator Online API has documentation and even C# sample code here.  Newsgator also provides a web-based feed reader that’s optimized for iPhone (which is my ultimate online target) and a Windows Media Center-integrated web reader (which’d be a bonus for me with Vista Ultimate controlling my TV universe at home).  Hey, they even provide a Desktop client that integrates with the IE7/Windows RSS Store (though it’s unclear whether it syncs with NewsGator Online).  Plus there’s an Outlook-integrated client that has some of the capabilities of the Attensa Outlook client (though not the free price tag).

Rojo.com: unpublished API (or less?)

This one was mentioned on Wikipedia‘s article for Google Reader.  I wasn’t able to find anything on Rojo’s site about an API, but I did see a few sporadic mentions on the ‘net (e.g. Yuan.CC’s archives through 2005, a Rojo forum suggestion).  Unfortunately, as the discussion seems to center around “undocumented” APIs, I’m even less interested in this than in Google’s limited interface.

Bloglines: “it sucks a lot

According to the ETech 2006 trip report, “The Bloglines Sync API didn’t work for synchronization since it is mainly a read-only API for fetching unread items from Bloglines. However it is complicated by the fact that fetching unread items from Bloglines marks them as read even if you don’t read them in retrieving applications.”

NewsAlloy: cool but not there yet

Currently in Beta, this free web-based feed reader implements the “Blogroll API” (whatever that means), and provides both a rich web-based and a mobile interface.  Unfortunately, the developer has been struggling off and on to keep this project going, but it’s a really cool looking project.

Feedlounge: cancelled

Read here.

Gritwire: no idea

Gritwire Labs (where I’d expect mention of APIs to show up) doesn’t mention anything about APIs.  The author once mentioned “It relies on an XML API to receive and provide data to the backend”, but there’s little if anything else that would help me understand what this “API” is used for.

Conclusion #1: Build a Generic Sync add-in

I’d started my solution as a Google-Attensa app (heck, I’d named it GoogleReaderSyncToAttensa).  Now, after looking into this, and not seeing any one clear “winner” among the online web-based feed readers, I have decided that the only responsible thing to do is to build this add-in on the assumption that others’ll want to add their own web-based readers to the codebase.  Thus, all the direct button-to-codebehind and code-to-Attensa calls should be abstracted as much as possible to not tie the code to any one web-based reader.  The idea is to make it as *easy* as possible for someone to add their own assembly/class that encapsulates the necessary site-specific functionality, and (ideally) not have to rewrite any of the existing code, other than to call into the appropriate assembly/class.

Heck, if I was feeling really generous, I’d even consider abstracting the Attensa interface so that Microsoft’s IE7 Feeds interface could be used as the local client, or even the inevitable Google Apps offline reader.  However, I’m getting waaayyy ahead of myself with this kind of thinking.  I’m going to have a hard enough time abstracting the remote site interfaces, let alone try to wire the classes for “plug and play” with various local feed reading apps.

Conclusion #2: I Should Just Cough Up the $30 for Newsgator Inbox

At my core, I’m just a lazy guy.  If I can find a pre-built application to do most of what I want to do, then I’ll suffer with the pain of that rather than go off and “build” something myself.  That was the core lesson I learned from Comp Sci 1A03 (first-year programming) in undergrad, and my computing bias was solidified that way ever since.

After looking at the breadth and depth of offerings from Newsgator (SOAP API, REST API, Outlook client, Windows Feed Store integration, iPhone web client, Windows Media Center client, and broad support for synchronization among all the feed readers) it feels like a tough choice for me: spend a few months developing a synchronization framework between Attensa and one or more online feed readers, or spend the $30 on Newsgator Inbox and postpone development indefinitely.

I guess the big question is, am I more interested in learning how to code Outlook VSTO and Web Services (SOAP and/or REST), or am I really just interested in getting on with my RSS reading and work on something else?  I do have plenty of other development projects I can continue doing, and it’s not like I have all this spare time to devote to multiple concurrent development projects.  On the other hand, this is an interesting space for development, and (for those folks not paying $$ to Newsgator yet) there’s something to be said for laying the groundwork for a generic offline-online RSS synchronization framework.

I’m going to have to sleep on this for a while — this is not an easy choice.

Advertisements

5 thoughts on “What if Google Reader had a sucky API…?

  1. A few corrections and clarifications on what you discovered and researched.Google, Microsoft, and Yahoo! each have their own authorization APIs for the exchange of user-specific data. You’ll need to grab a token from each system after passing the user and his or her login info to the service for verification of both your app and its intended use.I have not kept up with every iteration of the Google Reader API since I first pulled it apart but it’s not SOAP. Google Reader, like many Google Services, is based on GData (Atom + OpenSearch + Google namespace). You GET, PUT, etc. and react to both the HTTP Status returned and the body of the response.Bloglines should be a pretty easy implementation. You’re just pinging them with a userid and a site ID when the feed is read. They take that timestamp and clear all unread items from your feed view.

    Like

  2. <>Niall<>, thanks for your clarifications. I certainly wasn’t trying to provide a catch-all for how to work with these APIs, but I appreciate you making sure these details are represented so other unwitting Internet spelunkers don’t get caught unawares (as I’ve been many times).Sorry if I mis-appropriated your very hard work on the Google Reader API. What you describe sounds even *more* unwieldy than either SOAP or REST.As to Bloglines, if I was only trying to reflect my current read status to an occasional browse through the web, that’d be sweet. Unfortunately I’d really like to never have to waste time again with an article I’ve already read somewhere else – whether that’s on the web, in my fat client, or somewhere else. Most fat clients are nothing more than a browser shell when it comes to presentation fidelity, so I wouldn’t feel like I wasn’t getting a reasonable representation of my feeds when browsing them online. Thus, to me, the article would be just as “read” as if I’d read it offline. YMMV.

    Like

  3. <>Mr. Niesen<>, thanks for following up on my cranky comment. 🙂I was about to vehemently disagree with you, but when I fired up Attensa today and tried <>again<> to configure the Feed Server to that address (and using my old account and password), this time it worked!I am 99.9% sure that I tried this <>same<> set of steps at the time of writing, and that the server either wasn’t responding, or considered my account disabled/missing/unusable.Now, while I’m happy to have this online sync capability for myself, I feel compelled to ask, on behalf of the three or four other folks that read my blog 😉 – will Attensa make an online feed server (a la the seemingly-defunct Attensa Online) available for the users of its Windows/Mac/Outlook clients? If I have an account on your internal server, cool; but that doesn’t help the hordes who’re using the Attensa client without a corporate online server with which to sync.However, it *will* probably make me take a closer look at the Attensa Feed Server API, to see if I can build a lightweight sync engine for Windows Vista Media Center’s RSS client. 😉

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s