Future of the StatusNet API

From StatusNet

Jump to: navigation, search


[edit] Brainstorming points

  • Things we may or may not want to do -- a discussion.
  • autodiscovery of API base
    • <link rel="twiapi" link="/mublog/index.php/api">
    • 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

[edit] API improvements

  • Awesome API documentation (generated via Doxygen)
  • 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
  • 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.
Retrieved from "http://status.net/wiki/Future_of_the_StatusNet_API"
Personal tools