API endpoints

[devongovett]

The API routes are grouped into sections based on the data type they are editing, in the src/api folder. So far, I've implemented the majority of user info and authentication APIs, so everything else is fair game.

See http://undoc.in/api.html for a list of APIs supported by Google Reader. We will support a subset of these, excluding some of the social stuff, recommendations, and google specific stuff. Here's the subset I want to implement to start with. Except for the routes starting with /accounts, all routes begin with /reader/api/0.

User/auth stuff (done):

/accounts/ClientLogin
/accounts/register (not taken from google)
/token
/user-info

Streams (done):

/stream/contents/user
/stream/contents/feed
/stream/details
/stream/items/ids
/stream/items/count
/stream/items/contents

Subscription (done):

/subscription/edit
/subscription/quickadd
/subscription/list
/subscription/export
/subscribed

Tags (done):

/tag/list
/rename-tag
/edit-tag
/disable-tag
/unread-count
/mark-all-as-read

We may also need some of the routes under /preference as well (done).

Additional documentation:

• http://ranchero.com/downloads/GoogleReaderAPI-2009.pdf
• http://code.google.com/p/pyrfeed/wiki/GoogleReaderAPI

Edit: Most of these are complete, but there are some TODOs listed in the code where something is missing or not quite right. Also see the OPML issue. More testing doesn't hurt either, if you're looking for something to do. :)

[cvigano]

I am having a look into the subscription API and give it some love. Any hints or further reading material for this?

[devongovett]

What specifically are you looking for reading material on? All the API docs I found are listed in the issue description. Unfortunately, it's not an officially documented API by Google...

[cvigano]

A hint on what is the most current guess for the Google Reader API would be nice. In one of those docs you posted I found some more static c request parameter think which looked a lot like a Google-internal application / API identifier of some sort: c: CKL2t6j30KICSPTQ3f2hhawC (http://undoc.in/stream.html)

Is that needed? Or is this something we choose only once and stick with it as we will be the ones providing an API now?

[devongovett]

There's a glossary here that describes some of those parameters http://undoc.in/glossary.html. It doesn't look like a required parameter to me. I think we'll see which params are important once we start testing what apps using the API are actually using. For now, I think you could ignore that.

[devongovett]

Also, lots of the APIs take ck and client parameters, which we should just ignore. ck is used to prevent clients from caching, and we don't care what client is accessing the API for now.

[admdly]

Is there anything still missing on this? It looks like the OPML issue is now closed and all the noted endpoints look done.

I'm looking to begin using this project and I'm happy to jump into development and help out in this area where I can.

[lzanita09]

I've been using the project since it launched, currently it works well.

[devongovett]

All of the API endpoints listed here are implemented plus a few more. Some of them aren't quite complete though, see TODOs in code for that. And I'm leaving it open for other APIs to be added. Pretty sure we'll need the profile API and possibly at least stubs that return nothing for the others (e.g. friends, which I don't intend to support) so as to prevent 404s at least. The fetcher is what needs the most work at this point.