Yesterday Bloglines announced their API, which is a RPC/REST interface to their core functionality: unread message count, subscribed feeds / items and blogrolling. While the service URL is http://rpc.bloglines.com/<whatever>, they’re also using HTTP rather directly, specifically in terms of authentication and response codes … mostly correctly even (the 403 in response to listitems should really be a 404, no?)

Open service APIs are awesome; bloglines continues to r0×0r.

I can’t help but wonder why the API isn’t:

GET /user//unread

same plaintext as currently

GET /user//subs

returns the same OPML, with full URLs for the bloglines subscription id of the form…

GET /user//subs/12345 GET /user//subs/12345?since=

returns RSS of feed, with optional date.

POST /user//subs/12345 [simple form indicating that items should be marked read]

I guess you could use GET to modify state, but why? The POST is better-suited.

GET /user//

provides a listing of all of the above, plus more?

Advantages: 1. consistency — both getitems and listsubs? Why am I calling the update RPC to get an unread item list? 2. extension — there’s now a natural resource-space for extension and growth. 3. simplicity — this seems simpler.

Also, a note to API authors: hey, buddy, it’s 2004. You really don’t need to condense sinceLastReadDate to d, or complexActionCode to n … especially when you’re about to give me back super-verbose XML. kthxbye.

In fact, I started to write a aggregation web service not too long ago with a very similar API. Frankly, I love the concept of an aggregation service, but hate web based UIs; luckily the Moz* browers have created a nice, extendable web-browsing platform, which could be an excellent interface to such a service — or really any other.

The UI of a desktop aggregator; the advantages of a web-service approach.

Maybe someday I’ll pick up the thread.