Application Programming Interfaces (APIs) and the technologies and platforms that enable them, can bridge this gap. APIs can act as doors to previously locked information assets and key business functionality. APIs are already enabling millions of user experiences through a wide variety of devices such as smartphones, tablets, smart watches, bots to name just a few.
However, APIs are not new. APIs have been around for almost as long as there has been software development. In the early days of IT, APIs weren't anything like what we typically think of them today, but they have always embodied the same basic goals, namely a contract (explicit or implicit) that describes the data to be exchanged and an action. Today when we talk about APIs, we mostly refer to a specific type, REST APIs (also known as web APIs):
In the days of COBOL (Common Business-Oriented Language) for example, the interface was often described through files containing structure definitions. As programming moved on to languages such as C, we saw interfaces become more explicit through things like header files.
As interface definitions developed within programming languages, the problem also needed to be addressed in distributed solutions. This resulted in the rise of frameworks like CORBA (Common Object Request Broker Architecture) where we saw contracts being defined with IDL (Interface Definition Language) combined with communications standards such as GIOB (General Inter-Orb Protocol) so information could be inter-exchanged among programs in distributed networks.
This type of rudimentary APIs had a problem, though. They either had aspects of the interface not clearly defined to understand the definition you had to interpret the actual code, or they were very restrictive in terms of the communications protocol, for example, RMI (Remote Method Invocation) for Java and IIOP (Internet Iner-ORB Protocol) for CORBA.
With the arrival of the Internet HTTP (Hypermedia Transfer Protocol), the protocol that truly enabled the World Wide Web, it was not long before new and more open protocols emerged. The use of HTTP, combined with the XML (Extensible Markup Language), gave birth to one of the most popular standards in modern distributed computing, SOAP (Simple Object Access Protocol). Along with WSDL (Web Service Description Language) as an interface definition language, both would be used in combination as the foundation to define web services.
It at this point that SOA (Service Oriented Architecture) was conceived. A vendor-neutral and open architectural style based on the notion that services, as core building blocks, could be composed in order to create more flexible solutions.
And the Enterprise Service Bus (ESB) was born. Introduced as the main mechanism to realize SOA, ESBs represented the evolution of traditional EAI (Enterprise Architecture Integration) tools. However, instead of using proprietary protocols, they used open web services standards. This made ESBs extremely popular to the point that most organizations worldwide still use ESBs to satisfy many of their integration needs.
ESBs delivered many good benefits, and for many years they satisfied common integration requirements. But as mentioned at the start, an inflection point would take the entire IT industry by surprise.
With the increased popularity of mobile apps and the wide availability of cloud computing (at this point becoming popular among large enterprises), REST (Representational State Transfer) is introduced as a much simpler and more efficient way to implement services. Only that they were not referred to as services but web APIs. Although not enforced by the REST specification itself, most REST implementers favor JSON (JavaScript Object Notation) over XML the format to send data in REST.
This new way to provide access proved to be much more lightweight and simpler to adopt than its SOAP/WSDL predecessor and quickly rocketed in popularity.
ESB/SOA vendors, while trying to keep up with new demands, quickly adapted their 1st generation SOA stacks and XML appliances to also support REST/JSON capabilities, giving the vendors at least some time to digest what was going on in the industry. These are known as 2nd generation API platforms; these are just adaptations of ESBs and XML appliances to support REST APIs:
Some vendors, however, truly acknowledging that there had been a fundamental change in the industry, understood that just putting lipstick on a pig wouldn't do. They understood that information had become federated, that access via APIs had become the new standard; but most importantly a new way to construct services, a new kid in the block, had arrived to stay: Microservices Architecture.
