Print

Zeichick’s Take: The API as an overloaded operator



Alan Zeichick
Email
November 28, 2012 —  Once upon a time, application-programming interfaces were hooks that applications used to tap into operating system services. Want to open a port? Call an API. Need to find a printer? Call an API. Open a winder? Call an API. Write to a file? Call an API.

Developers still use classic APIs, of course. They are necessary for both native and managed code. Windows, iOS, Android, Unix, Linux: All are stuffed to the brim with hundreds and thousands of APIs. In fact, one of the most useful features of an integrated development environment like Visual Studio, Eclipse and Xcode is that they provide a handy reference to APIs, check their syntax and arguments, and help fill them out with autocomplete

Classic APIs are fundamental. Cloud-based APIs, which provide loosely coupled function calls to services over the Internet, are sexier and more dangerous.

The December issue of SD Times contains a feature by Alexandra Weber Morales, “Connecting the World with APIs.” She explains that the variety of cloud-based APIs far exceeds the biggest, most visible examples, such as those from Amazon and Google. APIs are everywhere, from social media players like Facebook and Twitter, to business services like MailChimp and Salesforce.com.

Like electricity from the wall socket, or water from the kitchen faucet, it is easy to take cloud-based APIs for granted. Too easy. We outsource core functionality of our applications to cloud-based services, some free, some paid for by subscription. We expect them to work consistently. We expect them to be monolithic and unchanging. We expect them to be fast. We expect them to be secure.

We must not make any of those assumptions. Our software must be able to detect if a cloud-based API is offline or is running slowly, and should be able to handle such a situation gracefully (i.e., not hang or crash). We should never assume that APIs are secure and will keep our data or our customers’ data safe. We should not expect the API vendor to proactively notify us if they change some of the functionality within the APIs. It’s our job to be on top of any changes.

The availability of cloud-based APIs—unlike operating system APIs—is out of our hands. Our decision to upgrade a server’s OS is on our schedule, and we have time to read the documentation. When a mobile platform maker, like Apple, Google or Microsoft, releases a new operating system, we get plenty of notice and have plenty of time to understand the newest APIs, the changed APIs and the deprecated APIs.

Not true with cloud-based APIs. While the three-letter acronym may be the same, our applications’ calls to a RESTful cloud-based APIs are not at all the same as our applications’ calls to native operating system services. While convenient, cloud-based APIs are ephemeral, distant and fundamentally unreliable. Never forget it.

Alan Zeichick is editorial director of SD Times. Read his blog at ztrek.blogspot.com.




Related Search Term(s): APIs, cloud


Share this link: http://sdt.bz/37199
 
Most Read  Latest News  Resources


Comments


12/07/2012 07:00:13 PM EST

Bravo!

United StatesMichael


close
NEXT ARTICLE
Open Cloud Initiative envisions an open cloud future
Vendor lock-in is a hidden danger, so principles must be established to protect users Read More...
 
 
 




News on Monday  more>>
Android Developer News  more>>
SharePoint Tech Report  more>>
Big Data TechReport  more>>

   
 
 

 


Download Current Issue
MAY 2013 PDF ISSUE

Need Back Issues?
DOWNLOAD HERE

Want to subscribe?