Still don’t believe every company will have APIs? Drug store Walgreens is a 100 year-old company that is a common street-corner sight in US cities. Now the company has launched its first Walgreens API for its popular photo department.
Most of the projects I work on as a contract developer involve some kind of 3rd party API integration. Because of that, I tend to think there should be an API for whatever external thing that needs to be done. A good amount of the time there is – if you need to send email, push real-time updates, offload data storage, deliver faxes, even hire someone like me, there really is an API for that. However, occasionally I run across some case where there is no API, even though it certainly seems like there should be. Maybe I’m just not throwing the right terms at google, maybe there aren’t really that many use cases, but every once in a while I think, “Shouldn’t there be an API that does [that]?”
The business social network LinkedIn is shutting off access to its LinkedIn API for one company over what LinkedIn calls a terms of service violation. Headhunting app Pealk released a notice that it “will be no more” by next week. It raises the importance of reading the legal details, as well as the different definitions of open.
It’s time we talk, Facebook, before you do something you’ll really regret. You see, I noticed you with that look in your eye again. The sort of look that marks the end of a promising young company and along with it a well-loved API. You say you’re changing, but I’m not sure I can ever trust you. Let me tell you why.
APIs are no longer technical nice-to-haves. These three letters are being spoken in board rooms and used as the basis for business strategy. One place you can see the effects of API growing up is the sheer number in our directory. But big numbers only tell us so much. In our many discussions with API providers, we’ve noticed a pattern with how many are approaching their platforms. These threads point to an alternate meaning for API: Apps, Partners and Income.
A recent PC World article titled “As Facebook Service Goes, So Goes the Internet” scratched the surface of some inherent dangers of our increasingly interconnected Internet. By its very nature, the current generation of the internet is interconnected: “Web 2.0 is a loosely defined intersection of web application features that facilitate participatory information sharing, interoperability, user-centered design, and collaboration on the World Wide Web.” The PC World article traced some problems that mere inclusion of a simple sharing interface can cause. When Facebook suffered a bad day, the top twenty news sites experienced load times of 12.5 seconds (compared to the usual 5-7 seconds). Top retail sites load times slowed to 5.7 seconds from the typical 2.2. seconds. All of this dragging because of a poorly performing “Like” button at a Facebook data center? This could have much larger implications for companies that are inherently reliant on data from external sources (e.g. websites pulling third-party data via APIs).
The number of APIs available across the public Internet has grown phenomenally in the past few years – with ProgrammableWeb’s directory now reaching 6000 APIs listed, with a 1000 APIs added in just the last 3 months.
While this number is large, it remains tiny compared to the many millions of sites that make up the World Wide Web. However, as code frameworks in major languages and platforms of various types make it increasingly easy to launch and operate APIs it is likely that “web scale” thinking will be needed to manage the resulting API Web.
With respect to Web APIs, the industry has clearly and emphatically landed on REST as the standard way to implement these services. And for good reason… REST, which is generally implemented as a one-size-fits-all solution, is an excellent choice for a most companies who wish to expose their content to third parties, mobile app developers, partners, internal teams, etc. There are many tomes about what REST is and how best to implement it, so I won’t go into detail here. But if I were to sum up the value proposition to these companies of the traditional REST solution, I would describe it as:
Why did Pinterest remove its API documentation earlier this year? Well, apparently there is no rush to release an already developed API to the public yet. In fact, it may not be released for a while as Pinterest wants to avoid re-tweeting the #mistakes Twitter made in its infancy.
As APIs have matured, we’ve celebrated the most popular ones by welcoming them to the API Billionaires Club. The billionaires are those who measure API requests in the billions–many per month, a few per day. While it’s been a good benchmark thus far, there are downsides to using it: API requests is dependent on many things about an API. In many cases, more requests is not a good thing for either the provider or the developer. It reminds me of the early dot com days and the focus on hits, a mostly meaningless stat with a few similarities to API requests.
©ProgrammableWeb.com 2013. All rights reserved.
Terms of Service | Privacy Policy
