Re: Reader API Questions

On 1/4/06, NickLothian <nick.lothian@gmail.com> wrote:
>
> Is this an appropriate place to ask questions about the Google Reader
> API
> (http://www.niallkennedy.com/blog/archives/2005/12/google_reader_a.html)?
>
> Assuming yes here are some specific things I'd like to know:

The API isn't offficially released or documented, but I can provide
some unofficial answers.

> 1) Is there any way to get the logged on user ID (the /user/000...000/
> number) programatically?

No, but one trick you can use is to substitute "-" for the user ID. In
this scenario, Reader will infer the user ID from the currently logged
in user.

> 1a) What are the implications of letting your user ID be known? I'm
> guessing this is a privacy thing so you can share your tags without
> someone knowing who you are (like the way Yahoo's MyWeb 2.0 sharing
> works with the hashed user id). Is that the only reason to keep it
> private?

Yes, that's pretty much the only reason. Merely having someone's user
ID doesn't let you get at their data.

> 2) The /reader/atom/user/000...000/ urls all seem to require a valid
> Google SID cookie. This makes "managing auth issues daunting" to say
> the least - using proxied XMLHTTPRequests won't really work. Any
> suggestions?

Authentication is one of the reason why the API hasn't been released yet.

> 2a) I'm thinking of working around the cross-domain issues using a
> signed script in Firefox (this is just for fun, so cross browser
> compatibility isn't a problem). That works okay - the request goes to
> Google.com with the correct cookie. However, I'm a little concerned
> about the possibility that a subscribed feed could inject dangerous
> content which would be run with elevated browser privileges due to it
> being in the context of the signed script. How much stripping of the
> HTML do you do?

We're pretty careful about HTML sanitizing (we have a whitelist of
tags), since malicious HTML could already affect us (it would allow
the user's Google cookie to be stolen).

> 3) I don't like the "river-of-news" view that the reading-list API
> seems optimized for. I'd prefer to be able to get read/unread
> infomation on a feed-by-feed basis, because I prefer my aggregator to
> work more like bloglines. At the moment it seems the only way to get
> read/unread information is to use the reading-list or
> /state/com.google/read APIs, paging though using the
> <gr:continuation>XXXX</gr:continuation> stuff (not sure when to stop
> paging here, though) and then build a lookup map of the read items
> which gets queried when I look at a specific feed. Is there a better
> way?
>
> 3a) My ideal solution to the problem above would be a per-user feed API
> (like http://www.google.com/reader/atom/user/0000....0000/feed/<feed
> url here> ) which includes the read/unread information.

You can get this right now. Simply request /reader/atom/feed/<feed
url>. It will have the read/unread state of the currently logged in
user.

> 4)
> http://www.google.com/reader/atom/user/000...0000/pref/com.google/subscriptions?complete=true
> seems really slow (20+ seconds). Is that normal?

I have ~300 subscriptions and it takes a couple of seconds for me. How
many subscriptions were you testing with?

Mihai