“It is a profoundly erroneous truism… that we should cultivate the habit of thinking of what we are doing. The precise opposite is the case. Civilization advances by extending the number of important operations which we can perform without thinking about them.” — Alfred North Whitehead, An Introduction to Mathematics (1911)
What is an API?
Per Wikipedia: In computer programming, an application programming interface (API) is a set of subroutine definitions, communication protocols, and tools for building software.
If you performed a quick Google search, that is pretty much the de facto definition that comes up in most pages you visit. Or you probably ended up landing on pages which had acronyms like WSDL, SOAP and REST leading you down other rabbit holes. Now you’ve ended up with more questions than answers. But there is a lot of meaning in that definition. Let’s take a look at the evolution of the API to try and unpack some of that meaning.
Evolution of the API
In the early days of computing, operating systems would offer APIs for an application to interface with the operating system. These early APIs were always local to the systems. For example, the Portable Operating System Interface (POSIX) specified a set of APIs that enabled an application written for one POSIX conformant operating system to run on another POSIX conformation operating system. Linux and BSD are examples of operating systems that conform to POSIX. APIs enabled portability.
Programming languages offer APIs that provide a specification of classes of class methods that would let developers quickly build software to solve business problems knowing the “expected behavior” of the API without having to know the “actual implementation” of the API. This concept would also be leveraged by libraries and frameworks. APIs provided abstraction.
Fast forward a few decades and APIs broke out of the local environment. Remote APIs allow manipulation of resources outside the system making the request through a communications network. APIs allowed integration.
Today, API is most often used to describe a web API because the most widely used communication network is the internet. Web APIs typically use web standards like Hypertext Transfer Protocol (HTTP) or Simple Mail Transfer Protocol (SMTP) for communication. Requests and responses are usually sent as Extensible Markup Language (XML) or JavaScript Object Notation (JSON) messages. Without getting into the weeds of technology and at the risk of starting a flame war, it is reasonable to say the recent trend of Web APIs is moving away from Simple Object Access Protocol (SOAP) and Service Oriented Architecture (SOA) based APIs to Representational State Transfer (REST) and Resource Oriented Architecture (ROA) based APIs.
So, what is an API again?
Based on the exceedingly abridged evolution, and looking back at that Wikipedia definition, we can see that, at a fundamental level, an API is a contract provided to you by a product or service that allows your product or service to communicate with it without having to know how they are implemented. Now how does this lead to automation?
The Compass Platform
Compass Automation Platform is our Managed CPaaS offering. Our goal for Compass is to be able to seamlessly integrate into our customer’s workflows and software systems while addressing their communication needs. We also want to continue developing Compass to keep pace with the rapidly changing industry. We believe that we can achieve this by building a modular system and leveraging the power of APIs.
Here are some design considerations that went into architecting Compass:
Not monolithic:
A single application cannot do it all. As time progresses, maintaining and adding features to a monolithic application becomes unscalable and error-prone.
A simple management portal:
Customers should have access to a simple and elegant management portal where they are able to service themselves and leverage the power of our platform.
Core services that provide key functionality:
Discrete functions like texting, emailing or making payments should be handled by separate APIs.
As you can see from the above, Compass is powered by APIs. These loosely coupled microservices allow faster delivery of new features and updates. Any service can be created, enhanced, replaced or dropped without affecting other services in the architecture. This architecture also allows us to optimize distributed resources as well as scale based on demand.
But what makes Compass truly powerful is that these APIs that power our platform can also power your product or platform directly. This is where real-time integration leads to automation.
The Sky’s The Limit
Today we take delight in the fact that we can build myriad solutions using the Compass platform for our customers who come to us with unique challenges.
What really gets us excited is to see how our customers would use the Compass platform to innovate and disrupt their respective industries and domains.