-By Hrishabh Sharma
Here are some definitions of API from various resources:
“In computer programming, an application programming interface (API) is a set of subroutine definitions, communication protocols, and tools for building software. In general terms, it is a set of clearly defined methods of communication between various components.” -[Wikipedia]
“An application program interface (API) is a code that allows two software programs to communicate with each other.”-[TechTarget]
Not only these if you search on any website about API, they will explain it brilliantly,
But it is only understandable by those who have worked on API, but if you haven’t then it can be difficult to fully understand, although the explanation is perfect but not in easy words.
The goal of this blog is simply to make you understand the meaning of API in more easy words.
So let’s begin with an easy example-
Suppose if you wanna book a ticket of a train, then it is possible to book tickets of the same train through various apps say IRCTC Official App, Paytm etc.
Now the main thing you need to understand is that how it is possible to book the same seat through two different Apps?
Yes, the answer lies in API.
What API is doing is just letting you use someone’s else code in your application.
Absolutely, PAYTM will be using API provided by IRCTC.
Take a look at this perfect video provided by Mulesoft:
I think you are now getting some idea of what API actually is?
Let’s look at another example-
Google is a huge website and it writes a tall pile of codes.
These codes are for various services like search, youtube, Gmail, etc. What if we want to use them?
You must have seen, many websites provide logging in through Google’s Login credentials in their apps. So in a second, you can log in on that third party app using your google account.
So what actually is happening behind this, third party-app is using Google’s API for providing login. In easy words, they are using Google’s code for the login system and fitting in their app and using their features, without worrying about what they have written.
Types of API:
Since this topic is very much wide…
Among all the types mentioned above , we will mainly focus on Web APIs aka Web-Services.
Web API as the name suggests, is an API over the web which can be accessed using the HTTP protocol. It is a concept and not a technology. We can build Web API using different technologies such as Java, .NET etc. For example, Twitter’s REST APIs provide programmatic access to read and write data using which we can integrate twitter’s capabilities into our own application.
Types Of WEB-APIs:
SOAP was designed back in 1998 by Dave Winer, Don Box, Bob Atkinson and Mohsen Al-Ghosein for Microsoft Corporation. It was designed to offer a new protocol and messaging framework for the communication of applications over the Web. While SOAP can be used across different protocols, it requires a SOAP client to build and receive the different requests, and relies heavily on the Web Service Definition Language (WSDL) and XML:
<?xml version="1.0"?> <soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-‐envelope" soap:encodingStyle="http://www.w3.org/2001/12/soap-‐ encoding"> <soap:Body xmlns:m="http://www.example.com/weather"> <m:GetWeather> <m:pinCode>395007</m:pinCode> </m:GetWeather> </soap:Body> </soap:Envelope>
Early on, SOAP did not have the strongest support in all languages, and it often became a tedious task for developers to integrate SOAP using the Web Service Definition Language.
However, SOAP calls can retain state, something that REST is not designed to do.
Before going to the next type, let’s understand a new term ,
RPC- “Remote Procedure Call (RPC) is a protocol that one program can use to request a service from a program located in another computer on a network without having to understand the network’s details.”
Apart from this definition, we can take it as a protocol working on the client-server model, without going much into detail
On the other hand, Remote Procedure Calls, or RPC APIs, are much quicker and easier to implement than SOAP. XML-RPC was the basis for
SOAP, although many continued to use it in its most generic form, making simple calls over HTTP with the data formatted as XML.
However, like SOAP, RPC calls are tightly coupled and require the user to not only know the procedure name, but often the order of parameters as well. This means that developers would have to spend extensive amounts of time going through documentation to utilize an XML-RPC API, and keeping documentation in sync with the API was of utmost importance, as otherwise, a developer’s attempts at integrating it would be futile.
JSON was then developed to provide a simple, concise format that could
also, capture state and data types.
Yahoo started taking advantage of JSON in 2005, quickly followed by
Google in 2006. Since then JSON has enjoyed rapid adoption and wide language support, becoming the format of choice for most developers.
You can see the simplicity that JSON brought to data formatting as
compared to the SOAP/ XML format above:
So, JSON presented a marked improvement over XML.
Now the most popular choice for API development, REST or RESTful APIs were designed to take advantage of existing protocols. While REST can be used over nearly any protocol, it typically takes advantage of HTTP when used for Web APIs. This means that developers do not need to install libraries or additional software in order to take advantage of a REST API. REST also provides an incredible layer of flexibility. Since data is not tied to methods and resources, REST has the ability to handle multiple types of calls, return different data formats.
Unlike SOAP, REST is not constrained to XML, but instead can return XML, JSON, or any other format depending on what the client requests. And unlike RPC, users aren’t required to know procedure names or specific parameters in a specific order.
I think uptill now, the question “what the hack is API?” is somewhat answered, but this description is not enough , there are many things you still need to explore on your own. So keep exploring.
Thanks for reading..
Happy Learning! ..
*Most Welcome to questions and doubts in comment section……….
#Objection accepted for copied images