Future of the StatusNet API

Brainstorming points

 * Things we may or may not want to do -- a discussion.
 * autodiscovery of API base
 * 
 * Is anyone else doing this?
 * 0.9.x: Implemented per API discovery using RSD; should be compatible with WordPress's implementation
 * versioning issues...
 * some other implementors are already providing multiple versions
 * but harder to maintain
 * and can make discovery harder?
 * account creation via api from clients?
 * realtime -> use Meteor/Orbited/etc?
 * "lite" API methods?
 * drop junk that's not usually needed like profile background image url on friends timeline
 * smaller, faster api returns
 * URL shortening fun...
 * make stats of targetted urls available, more analysis
 * built-in shortener (inside the firewall)
 * some visible way to request firehose xmpp access
 * [will pubsub replace that?]
 * most likely yes, but we don't have firehose pubsub yet I think

API improvements

 * Awesome API documentation (generated via Doxygen)
 * Integrated into rest of the machine-readable doc source
 * 0.9.x: this is starting: http://status.net/docs/api/
 * OAuth for protected API resources
 * 0.9.x: implemented
 * API versioning (version indicated in the URLs)
 * Different clients can use different versions of API
 * That way changes can be made without breaking existing clients
 * Evan's Concern: If we have global versioning, then a single addition of a parameter means we have to add another version of each other method
 * Decided to keep it Twitter compatible, which is global
 * Also, we already have extension that can check StatusNet version, we could do things like this anyway
 * For example: "Geolocation didn't exist before 0.9, so this one won't have it"
 * Discovery
 * Would be excellent
 * 0.9.x: implemented RSD: API discovery
 * rate limiting
 * API resource(s) for autocomplete/type-ahead data
 * Third party clients can have access to all the info we have.
 * API for administrative commands (create/delete users, suspend users, other admin functions)
 * Set up a new StatusNet instance via API?
 * Corporate installs possibly create users in batch?
 * Also, third party clients can have "Connect account, or create one"
 * Suggestions API (suggest a user/group, etc., list existing suggestions)
 * Resources for leader boards / stats
 * Emulate the Twitter real time web API?
 * Could be done with Meteor / Comet
 * Can we do this with a layer on to of xmpp? (wait, that sounds crazy)
 * implement our own track? (call it "gillmor" instead of "track")
 * Needs more design
 * Improve the search API
 * support operators -- booleans, from: to:, etc.
 * trends
 * Let people save searches
 * That way you can figure out what's the most popular searches.
 * URL Search API
 * API for conversations
 * Need whole conversation, and conversation from this point and all children
 * Resource to request latest attachments from a user / group?
 * Ask for last X attachments from a user, could be used for PodCasting, etc.
 * Twitter API very wordy, lots of hard to compute data
 * Most people don't care about most data
 * Don't need entire User Object every time
 * Could be value in making "Lite" methods
 * Cuts down on our bandwidth, processing
 * Makes API return faster, clients snappier
 * As we go forward, add extensions, how to make changes ethical, works with other clients
 * Conversation ID for each Notice, some clients may not understand.
 * If doing versioning, StatusNet extensions could only be in StatusNet versions only
 * Could add HTML into XML API outputs
 * Then clients don't need to parse it themselves
 * RSS 1.0 has lots of great data, Twitter Compliant RSS2.0 one has less.
 * Could do a lot more with our own StatusNet one.
 * Some ATOM could change with OMB 0.9, marked up with ActivityStreams, PuSH, Salmon, etc.
 * Need to decide if decorate Twitter API, or if have separate ones.
 * 0.9.x: implemented these extensions to Atom feeds for OStatus at existing Twitter API URLs
 * Could be easy to use StatusNet as base for lite versions of other networks, like Last.fm
 * This would require other APIs
 * Doing this would require completely separate API, not a lot of reuse possible
 * While talking about API, typically talk about Twitter API
 * We have other things, RSS 1.0, FOAF, Microformats stuff
 * Most devs aren't aware of that, but it could be useful to them
 * Should go in documentation
 * Web Service Discovery
 * Probably not useful
 * Might be, though
 * Might be useful to have a URL shortener inside
 * In this case, API required
 * Somewhat required for "Inside the Firewall" installs
 * If a post is linked to with ShortURL, it is fetched to deshorten the URL.
 * This data could be made available to people
 * Could also be used to find who has authority, because we know who posted a link, who follows it, etc.
 * Pagerank for people with Twitter
 * Trim: Does something like this
 * One of reasons we don't do it is it's not our business
 * Someone else with StatusNet site could do that, if they wanted
 * Could be plugin for Stats gathering
 * As much as we can get Devs to want to use our API for fun and cool things, the better.