Explaining what a backend developer does in his day-to-day job that’s one thing. Trying to explain what APIs are and how they work can shut any conversation down. The explanation that when a user clicks a button, a lot of logic happens in the background does not fully cover it. So for once and for all, let’s explain their history and importance.
An API or Application Programming Interface is the principal of a well-documented set of publicly addressable "entry points" for building and integrating application software. It is often referred to as a contract between a provider and a client.
Typically data is stored on a server, and to be able to retrieve that data, we expose a set of endpoints or, in other words, an API.
The history of APIs
APIs have been around as long as computing, but web APIs, as we know them now, originated when e-commerce took off around 2000.
As soon as the first ".com bubble" burst, platforms were looking for innovative ways to syndicate products across e-commerce websites, and web APIs, built on the back of existing HTTP infrastructure, proved to be the right tool for the job.
At the time, the API playing field was dominated by three companies: Salesforce, eBay, and Amazon. These companies are, to this day, very powerful and remain leaders in e-commerce.
In 2004, a shift in the API landscape began to emerge. Salesforce, eBay, and Amazon continued to iterate and evolve their own API efforts, but a new breed of API providers started to pop up. APIs were no longer only used for commercial value only but became lucrative platforms, with Facebook and Twitter as the most known examples.
As social platforms kept growing, a new transformation took place. In 2006, Amazon started offering basic cloud services. Amazon S3 and EC2 were released and changed everything. These 2 services demonstrated that web APIs could be used to generate revenue.
The next change in how we use APIs was in 2007 when Apple released the first iPhone. This opened a new world of mobile applications and how we interacted with mobile devices. Google responded by launching Google Maps, which started a wave of API-first startups.
In 2009, with the launch of the first iPad, icapps came into the picture as the first company in Belgium to launch an iPad application in the App Store.
In the evolution of IoT, a new generation of devices communicating with APIs via the cloud is being developed. These devices have new requirements which lead to next-generation APIs.
Different Web API services
There are 3 main types of API services, each with its own benefits and drawbacks.
SOAP
SOAP, or Simple Object Access Protocol, was mainly used before the existence of REST. It originates from the need for communication between different platforms or programming languages.
The main downfall of SOAP, and the reason REST originated, was its bad performance. The transfer of complex XML data tends to be slow and requires more bandwidth.
REST
REST, or Representational State Transfer, is unlike SOAP, an API design architecture. This allows greater flexibility of formats.
GraphQL
GraphQL is the newest kid on the block. Like REST, it is a design architecture for APIs. The primary difference is that GraphQL does not work with dedicated resources. Instead, every request or query needs to define what data it needs. The benefit is that only 1 API call is needed, and only the requested data is returned. So there is no unnecessary bandwidth used.
APIs by icapps
At icapps, we choose the right tools for the job; this is an integral part of our analysis, as every project has its challenges. In almost all cases, this results in a custom REST API for projects. With the fast evolution of APIs/projects comes the drawback of legacy code; our challenge is to use modern tools so that there is zero impact on customers.
Keep your eyes and ears open for our blog about how we put performance in front while developing applications.
What will the future bring for APIs?
We aim to help companies in their digital transformations; step by step, we automate services by writing custom APIs when necessary. This is not a one-day job, and it takes time and thorough analysis together with the customer.
We believe it is important to use the right setup for each project. Some projects may benefit from a service-orientated approach, others from a microservice setup instead of the default API setup.
