API & its Types

An Application Programming Interface (API) is a computing interface which defines

interactions between multiple software intermediaries. It defines the kinds of calls or requests
that can be made, how to make them, the data formats that should be used, the conventions
to follow, etc. It can also provide extension mechanisms so that users can extend existing
functionality in various ways and to varying degrees.
In building applications, an API simplifies programming by abstracting the
underlying implementation and only exposing objects or actions the developer needs. While
a graphical interface for an email client might provide a user with a button that performs all
the steps for fetching and highlighting new emails, an API for file input/output might give the
developer a function that copies a file from one location to another without requiring that the
developer understand the file system operations occurring behind the scenes.

1. History, Background & Evolution

The idea of the API is much older than the term. British computer
scientists Wilkes and Wheeler worked on modular software libraries in the 1940s for
the EDSAC computer. Joshua Bloch claims that Wilkes and Wheeler "latently invented" the
API, because it is more of a concept that is discovered than invented.
This observation lead to APIs that supported all types of programming, not just
application programming. By 1990, the API was defined simply as "a set of services available
to a programmer for performing certain tasks" by technologist Carl Malamud.
The conception of the API was expanded again with the dawn of web APIs. Roy
Fielding's dissertation Architectural Styles and the Design of Network-based Software
Architectures at UC Irvine in 2000 outlined Representational State Transfer (REST) and
described the idea of a "network-based Application Programming Interface" that Fielding
contrasted with traditional "library-based" APIs. XML and JSON web APIs saw widespread
commercial adoption beginning in 2000 and continuing as of 2020.

 SOAP operates with the two basic functions – GET and POST. GET is used to retrieve
data from the server, while POST is used to add or modify data.
 REST, in its turn, changes the state of the corresponding source by making a request to
the URI (Uniform Resource Identifier).
 GraphQL leverages requests of two types – queries retrieving data from the server, and
mutations changing the data.

 REST vs SOAP
The key difference between SOAP and REST protocols lies in their approach to
handling the app payload. SOAP, with XML used as data format, is far too verbose, both
on the request and the response side. The amount of data transferred within the SOAP
structure was enormous, thus requiring more resources and slowing down the
communication.
With the advance of mobile applications, this approach has quickly become
inefficient, as it affected their performance. REST with its endpoint requests seemed to be
a silver bullet, thus has rapidly turned into the protocol of choice among open API
architecture developers. A REST request, on the contrary, is more efficient, since its
structure is more plain and obvious. It contains all properties of the requested resource,
no matter whether the user needs it or not.
 Another disadvantage of SOAP was its support of a single data format, XML, while
REST could process XML, HTML, and JSON.

 REST vs GraphQL
While REST was a kind of a technology breakthrough in the area of API-oriented
architecture, it still left developers wanting more. When Facebook guys started looking for
a different way of fetching data from the server, they were trying to resolve the problem of
under-fetching or over-fetching that the existing API protocols had. In REST or SOAP, a
request for certain data returned all properties associated with it, even those the user did
not need.
GraphQL was designed to take care of this problem. When you make a data query
in GraphQL, you specify exactly what you wish to receive. Such results are achieved
through shifting the data definition functions to the client side, while in REST, data is
defined on the server side. In other words, in REST API architecture, the server defines
which data is to be returned, while in GraphQL API, the server only declares the available
data, and the client specifies what should be returned.

 SOAP vs GraphQL
GraphQL, being the latest innovation in the API architecture evolution, combines
the strong suites of both SOAP and REST. If we compare GraphQL and SOAP, we will
see that both use single endpoint URLs to fetch or modify the data. At the same time,
GraphQL is much more lightweight, thus reducing the network payload. Another similarity
between GraphQL and SOAP is strong data typing. Both protocols declare data types
explicitly, which ensures better communication between applications.
Having mentioned caching as one of the points worth taking into account, we have
to admit that in this respect both SOAP and GraphQL have nothing to boast of. Neither of
them has own caching mechanisms and needs to rely on additional tools.

2. API Frameworks
 Django is a Python-based free and open-source web framework that follows the model-
template-views architectural pattern. Django's primary goal is to ease the creation of
complex, database-driven websites. The framework emphasizes reusability and
"pluggability" of components, less code, low coupling, rapid development, and the
principle of don't repeat yourself. Python is used throughout, even for settings files and
data models. Django also provides an optional administrative create, read, update and
delete interface that is generated dynamically through introspection and configured via
admin models.
 Flask is a micro web framework written in Python. It is classified as a microframework
because it does not require particular tools or libraries. It has no database abstraction
layer, form validation, or any other components where pre-existing third-party libraries
provide common functions. Flask supports extensions that can add application features
as if they were implemented in Flask itself. Extensions exist for object-relational mappers,
form validation, upload handling, various open authentication technologies and several
common framework related tools.
 Laravel is a free, open-source PHP web framework, created by Taylor Otwell and
intended for the development of web applications following the model–view–controller
architectural pattern and based on Symfony. Some of the features of Laravel are a
modular packaging system with a dedicated dependency manager, different ways for
accessing relational databases, utilities that aid in application deployment and
maintenance, and its orientation toward syntactic sugar.
 Express.js, or simply Express, is a back end web application framework for Node.js,
released as free and open-source software under the MIT License. It is designed for
building web applications and APIs. It has been called the de facto standard server
framework for Node.js. The original author, TJ Holowaychuk, described it as a Sinatra -
inspired server,[5] meaning that it is relatively minimal with many features available as
plugins. Express is the back-end component of the MEAN stack, together with
the MongoDB database software and AngularJS front-end framework.