The limits imposed on open API usage policies by API providers such as Twitter, Facebook, LinkedIn and Google among others has sparked off a debate on the relationship between such restrictions and its effect on innovation. At one end of the debate are proponents of unrestricted public APIs to spur innovation, represented by Janet Wagner, writer at ProgrammableWeb, who illustrates the negatives effects of restriction by highlighting the lack of innovation in social networking apps. The other side is represented by Thor Mitchell from Google who believes that restrictions are an unavoidable consequence to protect the API provider's interests.
Janet in her article on ProgrammableWeb says:
This trend of closing platforms and restricting API access has led to the monoculture of the predominant social networking platforms where innovation has begun to decline or perhaps has even disappeared. The lack of innovation among the major social networking platforms has become increasingly apparent; breakout applications are few and far between, and the platforms have begun to look almost exactly the same.
The referenced restrictions come in various forms and have occurred over a large time-frame that starts from 2007. The various forms in which these restrictions are enforced include rate limiting, API deprecation, API terms of use, display requirements, API token limits and finally vetted API access. Coincidentally open API providers are revising their rate limits, which Patricio Robles introduced to the restriction vs innovation debate. Patricio summarizes the key take away on rate limits for API providers:
Pay attention to usage limits, and be thoughtful about them. There are enough instances of developers being burned by API providers to give them pause, so stability and clarity around usage limits is an important part of building and maintaining developer trust. And with the number of APIs growing, implementing sensible usage limits is crucial to attracting and retaining developers looking for the best opportunities.
Thor, on the other hand, argues that not all innovation is productive to API providers. Hence the need for restrictions to avoid unintended uses, which may harm business. He also emphasizes the fact that adoption is not a sufficient condition for success of an API product unless it translates into value. He summarizes his thoughts:
- The occasional introduction of API restrictions is an unavoidable consequence of the availability of unrestricted APIs.
- The more unrestricted an API is the more likely it is that additional restrictions will be added later.
- Attempting to persuade API providers not to add restrictions to their APIs because it will limit innovation is unrealistically idealistic because in most cases the restrictions being added are a response to innovation that proved damaging to the business.
- If your business depends on use of an unrestricted API in a way that delivers no value to the API provider you're taking an enormous risk.
As this debate ensues, developers continue to find ways to discover and use APIs not intended for public consumption. It may take the form of scraping data from the web or using HTTP proxies to capture private APIs used by mobile apps as illustrated in this blog post by Tim Rogers.
If you are an API provider, how do you strike this balance? Will gamification of API usage align the interests of consumers and providers?
