LOUNGE all new asksnapzu ideasforsnapzu newtribes interesting pics videos funny technology science technews gaming health history worldnews business web research entertainment food living internet socialmedia mobile space sports photography nature animals movies culture travel television finance music celebrities gadgets environment usa crime politics law money justice psychology security cars wtf art google books lifetips bigbrother women apple kids recipes whoa military privacy education facebook medicine computing wildlife design war drugs middleeast diet toplists economy fail violence humor africa microsoft parenting dogs canada neuroscience architecture religion advertising infographics sex journalism disaster software aviation relationships energy booze life japan ukraine newmovies nsa cannabis name Name of the tribe humanrights nasa cute weather gifs discoveries cops futurism football earth dataviz pets guns entrepreneurship fitness android extremeweather fashion insects india northamerica
  • drunkenninja

    There's a crucial step that's easy to overlook: Make sure you have a solid plan for how you're going to update your API. The ideal is a versioned API, where old versions are supported indefinitely. If that's not plausible for you, consider how you're going to communicate changes to developers with enough lead time for them to update their apps. (And you'll still want to version things, because it's no good to make everyone deploy at the exact same time as you.) Remember that since you don't have control over third-party code, even changes that seem totally innocuous to you might break things.

    Couldn't agree more, we plan to keep meticulous documentation, version control and a moving forward only approach with new API versions. We realize that changing even the most trivial functionality in the API can cause issues.

    It's often hard for a web company that's used to agile-style fast release cycles to get in the proper mindset for maintaining an API. The ideal is for breaking changes to be rare, and done with a lot of lead time. This can of course be different in a beta period, but communicate that heavily and plan to lock things in eventually.

    Yes, we do plan on having a beta period dedicated to working out the kinks.

    Thinking about the business side of things is also important. Start thinking now about what sort of apps you'd be tempted to try to shut down, and whether you're going to do that. Try to come up with a terms of service that you can live with for a long time, because nothing makes developers more wary of a company than them shutting down any third party service that gets too popular.
    Get all of that right, and you'll be head and shoulders above 90% of APIs out there. :)

    Some great advice here, thank you.