This blog has been updated from an earlier article
Think of the last time you ordered something online from say Amazon or your favorite web store.
What was your experience?
…Did you feel confident about the experience?
We’ll bet dollars to donuts that your Amazon experience was so positive, you didn’t even think about it as your added items to your cart, submitted your payment with one click through PayPal, and ultimately received your order in good condition shortly thereafter.
Surprisingly to many, APIs and data integration played a huge role in that experience. But what are APIs anyway, and why are they the EDI of the 21st century?
Keep reading to find out.
APIs are the new EDI
In the 1990’s and 2000’s, complex retail supply chains depended on EDI to transact electronic data between themselves and their supply chain partners. Typically partners transacted orders, invoices and shipment notices in non real time; EDI was store and forward technology.
Then along came the internet, and with the internet, APIs.
As web applications proliferated, the standard of commuication between applications became the API. So what is an API?
The technical definition of an API is Application Programming Interface. I won’t get into a super technical discussion on APIs, but envisage them as interfaces that allow you to access data in systems in real time. The applications can be on premise or in the cloud, or both.
APIs and the connections between them are the plumbing of the internet of things. To help set context, let’s review definitions first.
APIs can typically be divided into two categories – public and private.
Public facing APIs expose data to the outside world. Private APIs expose data to a protected inside world. As of this writing Programmableweb has catalogued over 14000 public APIs and over 7300 API mashups. Its huge.
So how do they work?
Well, APIs typically have a number of components which make up the API. The first is communications; the second is security and finally the payload, which is the actual data. So lets look at the two communications approaches that are widely used today; SOAP and REST. No, we are not going to wash up before going to bed.
SOAP is the granddaddy of API communication protocols and is defined as Simple Object Access Protocol. It is one piece in the web services stack and is usually paired with application layer protocols like HTTP and SMTP. The other application layers provide the security. The payload is XML. The current SOAP definitions by W3C were last updated in 2007, so some would say SOAP is getting a little long in the tooth.This brings us to REST.
REST stands for Representational State Transfer. What? You can relax, it’s not that complicated. The concept behind REST is that it uses simpler mechanisms to communicate rather than using more complex mechanisms like SOAP and RPC (Remote Procedure Calls). RESTful applications use HTTP to post, delete and read data. There are four HTTP methods used in REST; GET, POST, PUT and DELETE. Since REST is not a standard, there is pretty much anything that can be done with REST. Some have even postulated that the Internet is the largest REST application in the world.
So what is the difference between the two? First is the payload. The SOAP payload is XML where as the REST payload is XML, or JSON, or both. JSON is a lighter weight more compact message protocol. The second is the simplicity of the communications layer.
Understanding the nature of the API gives you a clear indication as to the complexity of the integration. Today, the API world is moving more and more to REST based approaches with the flexibility of an XML or JSON payload. As of the publishing of this article, REST accounted for over 9,000 of the APIs catalogued by Programmableweb.
Let’s now turn our attention to some of the business models solution providers have put in place.
Looking at the business model will help explain the type of integration approach and the role the application provider will play. It’s also the interesting part for non-techies: the business models are surprisingly complex.
There is a belief in the internet world that APIs and access to them are free, but in most cases that is not reality. In fact, in a blog article in early 2013 elasticweb identified 18 business models that existed in the world of APIs. By late 2013, Programmable web had identifed 20 API business models. The presentation below walks through the 20 models that had been identifed at that time.
What’s interesting in the deconstruction done by elasticweb and Programmableweb is that the top tier in reality represents only four models:
Free, developer pays, developer gets paid, and indirect.
Each of the last three then have multiple apporaches that reflect the application and their monetization strategy.
What these models tell us is that there are multiple integration strategies required depending on the type of solution one is building.
So aside from the monetization strategy, APIs are important to a business for the following reasons and should form part of a proper data usage and integration strategy.
APIs create stickiness; its no secret integration is time consuming and expensive. So, do it properly from the beginning. APIs are useful in extending the usability of a platform. The more third party applications that connect to an API the more extensive the use case for that solution is.