About the Google Reader API: I think part of the reason so many things rely on it, despite the fact that it isn't "supported", is that we actually designed an API for it. When we built Reader we decided that instead of trying to bolt an API on later we'd have our UI go through our own API. This would help ensure that our API was "complete" and would stay that way -- if you could do something in Reader, chances are the API supported it. (I feel like this is obvious, yet so many web apps don't do things this way.)<p>Our original plan was to document the API, but it turned out that there was a separate project going on concurrently to create a "standard" sort of API for Google products, GData. Reader's API wasn't GData compliant, and actually used a very different philosophy from GData. GData is CRUD-centric while Reader's API was pretty much just RPCs over HTTP. RPCs with side-effects would go over POST and those without would use GET. We also supported responses in either XML or JSON. GData used Atom for everything (something I found a bit ironic), though later GData added a sort of JSON support (really XML in JSON syntax -- Object literals with XML namespaces).<p>Anyway, my point is that GData was very different from Reader's API. We were told we'd have to GData-ify our API before publishing it since all new APIs were supposed to be GData. Nobody was really interested in doing that, so the only API documentation that exists is "unofficial".