The API Biography - Final Take 4 - Going Mobile

The advent of Web Services enabled APIs to be consumed from anywhere, be it desktops (PCs or Macs), other websites or embedded systems  with a zero install requirement. In parallel, the mobile revolution had begin to happen and smartphones and tablets were starting to gain some visibility. These early devices were primarily being driven by a stylus and had some custom apps making them look cooler than the usual phone and came to be termed by some as palmtops, PDAs and Pocket PCs (see a popular one on your right). Several software and hardware giants like Microsoft, HP and Palm tried to capture the market but the value for money and lack of human touch kept these to be limited to the business users or the enthusiasts.
It was Apple (once again) who with their usual creativity came with the idea of a do everything in a cool way smartphone with two key differentiating factors - a.)The human touch over a stylus and b.)An app store platform where any developer could build customised applications for it. Apple built in some natural gestures like press, long press, pinch, flip, rotate which made the phone seem natural and obvious to every end user out there. But what caused the explosive growth is the hundreds of thousands of apps and the marketplace which enabled users to continue to stay engaged with their phone and tablet. And where there are apps, there are APIs! Many of these apps were an extension to the user's desktop or browser and allowed two way magic - anytime/anywhere access to the data (pull model) and real time notifications (push model). For instance, one on their iPhone or Android could pull in their Facebook feed at any time and receive a push notification when their friend liked their picture or had their birthday. Similarly, one could read in news from anywhere on their phone/tablet and be notified when their favourite team hit a goal. This continuous connectivity, availability and flexibility (which app to chose) have made mobile devices in a few years give competition to decades of desktop and laptop computers. 

A lot of this magic is possible because of APIs. Facebook and your favourite news  app makes a web service request (API call) from the mobile device to the backend servers and parses the API response to display your news feed and live news at any instant. Similarly, your mobile apps register with the server to receive notifications which are sent through APIs The beautiful thing here is that often the same web service API (SOAP or REST) can be used for making requests and returning responses to apps on different devices and platforms. Hence, the web service API that was written by Evernote (a note taking service) to create a new note (POST in REST) and retrieve notes (GET in REST) of a user can now be consumed from their PC and MAC apps, their browser webapp and also the mobile app. They can also be used by 3rd party developers to build custom extensions and plugins that end users can install from the Evernote marketplace. That you see is the power of APIs!!

The API Biography continues - Take 3 - Web Services

Come mid 1990's it was time to get out of the box. Yes, literally! Till before this time, APIs were mostly about desktop applications calling into the Operating system or desktop applications calling into each other. But at this time, that is the Networking Era, the embedded industry, intranets and internet were starting to gain much visible presence. Hardware and software vendors wanted to communicate between applications outside / across the box - be it those running on desktops, or an chip in an embedded system. The problem was now even more interesting since these applications could be on completely different operating systems, written using completely different technologies and located in completely different locations. A common language or protocol was needed to communicate between these varied application and that resulted in the birth of Web Service APIs. 

The first in line was the SOAP protocol that was created by some top IT companies of that time like Microsoft and IBM. It began as the mechanics to do a Remote Procedure Call (RPC) over HTTP using XML but soon gained traction and became a W3C recommendation. Every big and small company that created web-apps started exposing their services or facilities through APIs so that other desktop and web-apps could integrate with their service. This was quite similar to the desktop app plugin model, but with no boundaries on consumptions. The desktop app plugins were limited to specific operating systems for consumption and after the user had installed the app and the plugin. In the web world, the web services APIs could be consumed from anywhere with zero install requirement. For instance, one could make a SOAP Web service call to get the weather of a city from a weather service, have a document converted to a PDF through a document conversion service or get the latest stock price from a financial web service.

In parallel to all this, the World Wide Web (www part of the Internet) was really picking up speed every day - proliferating faster than Agent Smith in the Matrix as it continues today. Notice in the pic above what all has happened in the minute you were reading this. The www was governed by the HTTP protocol and a growing collection of pages, resources and URLs. In 2000, one of the proponents of HTTP, Roy Fielding, presented his thesis that totally changed the face of Web Service APIs. Though SOAP had been growing aggressively, it had it's own problems of being procedural, heavy and complex to construct. Fielding proposed REST, an architectural style based on the standard www principles. With it's clean design around resources, URLs and CRUD operations (Create, Retrieve, Update and Delete), it looked so simple and obvious that it immediately got all the heat.  What was a thesis chapter back then, has now come to define how most modern web services like Facebook, Dropbox, Google and Adobe expose their functionality to their integrators. 

We will cover all this and more about REST Web Services and RESTful Design  through this blog. 

The API Biography - Take 2 - The PC and API revolution

If you have been one of the lucky ones to see or use a computer that started with the picture on the left - smile for you have witnessed the commencement of the API revolution. If you have ever read the book below or referenced it to write a line of code, pat yourself on the back. For you, have helped made the API revolution possible. And if you are reading this post, be proud. For you are now powered and have the knowledge to take it forward!



MACs have always been much more cooler than Windows based PCs, but the more than 90% share of PCs that existed for long has been largely there because of the thousands (now millions) of application software available on Windows. And these applications themselves have been possible due to the extensive set of APIs that Microsoft OS provides. Ok, lets talk more!! Whenever you create an app or software for an Operating System (OS), lets say Windows (or Mac), you need to talk and instruct the OS to do anything you want. This entire talking is done through APIs. For instance, to create the main window of application, there in an API called CreateWindow which takes a bunch of options (called parameters) like title of window, location, size, style etc. Every application running on windows needs to call this API to show it's first screen. The OS responds back to the API call with a Handle to the window which the application then uses through a device context (it's Ok to ignore this term!) to do more things like DrawText (another API) or CreateFile (yet another API). 

The ever (in)famous Message Box that you see here is also created using an API called MessageBox. And so are all the menus, toolbars, buttons and check boxes. These APIs have grown from few hundreds in the initial version of Windows to several thousands today. In fact, many applications have now started providing their own APIs so that other applications can integrate with them. The term plugins or extensions that you hear sometimes are these second level applications which are built using APIs created and provided by the core first level application. For instance, Acrobat provides APIs and a plugin architecture for other 3rd party vendors to integrate. You see, APIs are viral!

Here are some more keywords for further reading. On Windows, these APIs for the longest time were called Win32 APIs. In MAC, they are provided by the Carbon and Cocoa Frameworks. In Acrobat, there is a complete API SDK for building plugins. 

What is an API? And why do I care? Take 1 - ENIAC to the first Mac

The Google Directions API post got many of my non IT friends curious to understand what exactly APIs are and why they are important. Some also suggested a quick post and adding a Tag to distinguish such fundamental posts, and so I will use a tag for these and oh well, call it Fundamentals

APIs or Application Programming Interfaces are a developer's instruction manual to using a piece of functionality exposed by a desktop software or web service programatically. In laymen terms, they define how to make a request to a software/service and what response to expect from it. APIs have a fairly long history in the world of computers and lets go back in time to discover how they came into existence. In the olden ages of computers, these multi-story devices (one of the first call ENIAC on your right) were primarily meant for the purpose of research, security or for giant institutions and available only to a rare few who had millions of dollars to spare. Several years later, some great companies like Apple, IBM and Microsoft and bright minds like Steve Jobs and Bill Gates came with the concept of personal computers and operating systems with the vision of taking computing to the household. That was in 1980's, some 30+ years ago!

It started with funny looking machines (and Ads :-)) and command line OS and soon GUIs (Graphical User Interfaces) started showing up. To your left is Steve Jobs presenting the first Mac in 1984!

These bright and cool guys (aka geeks) knew that they could not develop every piece of functionality on their own and why should they? For instance, on the software side they would focus on some basic (calculator), some fun (Solitaire) and some core business (Office) things and leave the rest to other third party developers.   They would create an ecosystem in which these things, called apps, applications or software would get created. And this ecosystem was to be largely driven by APIs. And guess what, even 30 years later it continues to be driven by APIs. These must be pretty important.  How they drive your PCs and Macs - we'll talk more in the Take 2