Web APIs are now widely used for integration, especially to enable mobile applications. APIs divide broadly into two categories: Open APIs and Enterprise APIs. “Open APIs” are APIs which are available to any client, often hosted in the Cloud. “Enterprise APIs” run inside the enterprise and are not publicly available. So, how do Open APIs differ from Enterprise APIs? Let’s begin to answer this question by turning it on its head – what do Open APIs and Enterprise APIs have in common?
In this interview with Raj Kadam, CEO of Viralheat, we will discuss the growth of the company’s API and the steps that were taken to reach this point. Their Sentiment API is now getting 300 million calls per week, and the free API allows users to classify text with regard to sentiment.
Developing an API? Think product. That’s at the core of Ross Mason’s point in his devopsangle article, 5 Ways Not To Screw Up Your API Strategy. Mason, the founder and CTO of Mulesoft, uses Twitter’s API story as a jumping off point for what not to do (namely change the rules for APIs that then damage your ecosystem and anger developers).
The Mendeley API provides access to research tools and data. In the interview below we discuss with Rosario García de Zúñiga, Senior Software Engineer & Team Leader at Mendeley, how she sees the future of open APIs. This interview is part of a series conducted by ProgrammableWeb and Hojoki (where I work), an aggregation tool for apps such as Google Drive, Dropbox and Evernote, that helps support team work.
I recently had the opportunity to moderate a panel for the Massachusetts Technology Leadership Council where the subject matter was “The API Revolution.” In the hour long discussion, the panel, which included members from industry leaders like Brainshark, Akamai and Constant Contact, wrestled with several topics that I think most companies are grappling with – 1) which APIs do you expose, 2) to whom do you expose them, 3) do you make the investment to build new ones, and 4) how do you leverage any of them for revenue.
The Zendesk API is designed to automate and enhance customer support. In the interview below we discuss with DeVaris Brown, Technical Evangelist for Zendesk, how he sees the future of open APIs. This interview is part of a series conducted by ProgrammableWeb and Hojoki (where I work), an aggregation tool for apps such as Google Drive, Dropbox and Evernote, that helps support team work.
Remember when Mark Zuckerberg blamed the problematic old Facebook mobile app–dubbed “freakishly slow” by some–on “betting too much on HTML 5?” So does backend-as-a-service (BAAS) provider Sencha, and to rebut Zuckerberg’s assertion that using HTML5 was “one of [Facebook's] biggest mistakes,” Sencha built its own mobile webapp, Fastbook, to demonstrate that HTML5 is ready for prime time.
If you’re building a library for others to use, whether an internal utility at your company or a full-scale commercial API, elegant error handling is a much appreciated but often overlooked design consideration. Having a sensible error-handling system for your library is even more important in client-side frameworks like javascript, where the code has to deal with network connection issues, a weak type system, and a mutable and potentially hostile context, all while striving to maintain as small of a footprint as possible. While some of these points on error handling are applicable to APIs in general, this advice is drawn from how we at Filepicker.io looked at communicating errors in javascript API design.
In a post over at PandoDaily last week there was some discussion about the trend towards Single Page Web Applications (SPAs) that seems to be emerging especially for SAAS Web Applications (see Zendesk’s great post on Techcrunch last week). Single Page Web Apps are just starting to gain currency, but may end up playing a major role in API adoption since they essentially eliminate the need for “page based” navigation within an application. Instead, SPAs rely on a combination of an API and Javascript to create the user experience. It also seems likely that this trend might eventually extend even to content Web sites, not just functional applications (some thoughts on this here: The Death of the Web Page.
FullContact’s CEO, Bart Lorang, has just posted the company’s 5 Laws of Privacy. Small wonder–they are in the business of upgrading your contacts by providing an address book in the cloud that fills in contact details. Any user would have a simple question: what happens to data I give to the company?
©ProgrammableWeb.com 2013. All rights reserved.
Terms of Service | Privacy Policy
