|By Mark O'Neill||
|January 27, 2014 09:30 AM EST||
Until recently, when I would talk about "APIs", I would qualify it by saying "Web APIs", in order to distinguish from the older meaning of APIs as more the tightly-coupled APIs used in Java, C/C++, or even Visual Basic. If you just said "APIs", until recently, some people may think you mean APIs like the Windows API (I can remember Charles Petzold's excellent Windows API book was on my desk back when I was a programmer at an EDI VAN in the 90s).
Recently Kin Lane has posted some good questions about the nature of APIs on his blog - he begins by explaining:
Just exactly what an API is, is always up for debate. APIs have been around since before the Internet. API Evangelist focuses in on what I call web APIs, that were built using the same technology as websites, and were made even popular for delivering valuable data and resources to mobile phones.
Notice "Web APIs" also. But, Kin explains that technology may be moving on. Recently, I have seen APIs move on from just "Web APIs". This is for two reasons. Firstly, people know that "APIs" means the modern meaning of the term, so there is less need to qualify what you mean. But secondly, and more fundamentally, there is now a realization that APIs refers in the broad sense to how businesses enable new channels, using technology links to devices, partners, and the market in general.
Kin goes on to ask
" What will happen with the Internet of Things? Will there be APIs that are tailored for home automation devices or just our cars?"
It is true that Internet of Things is bringing in a broader meaning of "APIs" to go beyond "the same technology as websites", and towards more tailored protocols and data formats (even JSON is too verbose in many Internet of Things scenarios).
Here at Axway, we see that customers see their API as encompassing not only HTTP+JSON style Web APIs, but also including their B2B interfaces, so it's "API in a broad sense". A business may use a variety of protocols, including EDI, ebXML, and Managed File Transfer as part of its overall "API". An "API" is now you can automate business across the firewall, not limited to a particular set of technologies. Just like with SOA, it's important to disassociate the architecture from the enabling technology. I think this is a very useful debate kicked off by Kin Lane, and it chimes very well with what we're seeing at Axway in the B2B and Internet of Things markets.