The APIs of companies like Twitter and Facebook seem to have a history of complaints from developers as they constantly change to the detriment of devs and the benefit of the company. There seems to be a cycle of openness at the start to encourage growth and then after some time the company with the API starts to make it more strict and tightens how devs can use it.<p>With all the lessons over the past few years, is there a model now for an API which can better maintain a good dev relationship without really hampering the company with the API?
This really depends on the type of business behind the API. Transactional API models have worked really well (Expedia affiliates, payment gateways, messaging). It's really only been a problem for providers who didn't properly align their interests with the consumer of the API meaning one side of the equation was getting far more value than they were contributing. This tends to be most common in consumer service APIs.<p>I wrote a little bit about this here: <a href="http://thenextweb.com/dd/2013/03/12/apis-are-dead-long-live-apis/" rel="nofollow">http://thenextweb.com/dd/2013/03/12/apis-are-dead-long-live-...</a>
To see a model for this, look to companies with B2B DNA. Facebook and Twitter are used to taking a "PM knows best" b2c approach, not a "customers first" perspective. Salesforce REST is a good example from larger companies (disclosure - my cofounder was one of it architects), and Stripe's API is a great example from the startup world.<p>From studying these, I found that the best practices aren't all that surprising: versioning, discoverability, and following HTTP standards.