Volume 7, Issue 6, June – 2022 International Journal of Innovative Science and Research Technology

ISSN No:-2456-2165

REST API Applications Vs Monolithic Applications

Swanand Anand Kolekar
Master of Computer Applications
ASM IMCOST
Thane, India

Abstract:- This paper tackles the questions “Are REST  REST :

API applications better than monolithic applications?”  REST is an acronym for Representational
and “Is one better than the other?”. This is answered via  State Transfer.
a comparative analysis of the architecture structure used  REST is a software architectural style created by
within both the applications via which it is concluded that computer scientist Roy Fielding.
whenever a scalable application is to be implemented  REST was developed to guide the behavior of the
REST api applications are better than monolithic architecture of hypermedia systems which operate on an
applications. Internet-scale.

Keywords:- REST; API;  For this REST has defined six architectural constraints
namely:
I. INTRODUCTION  Client-server architecture.
 Statelessness.
There often comes a choice at the beginning of a new  Cacheability.
project where the project architecture is to be decided on  Layered system.
which the scope of the project is dependent. The architecture  Code on demand.
style chosen to be implemented also affects how the  Uniform interface.
application will behave when there is a need to scale it to meet
the increasing business demands. In regards to this, this paper The above mentioned six constraints when used on
compares the architectural design of REST API applications distributed hypermedia systems enhances their non-
to that of Monolithic applications to determine which one is functional attributes, namely scalability, simplicity,
suitable for the business needs that come along with the scope modularity, visibility, and performance.
of the project in terms of scalability.
 Microservices :
II. RESEARCH METHODOLOGY  Microservices architecture is an architectural style used
for developing software applications.
A. Phase 1 : Concept Introductions  The core essence of microservices architecture is the
breaking down and separating a rather large scale
 API : application into smaller independent parts which create a
 API is an acronym for Application Program Interface. plethora of opportunities.
 APIs are basically software programs or software  Microservices architecture is best suited for Rapid
intermediaries that enable the communication between  Application Development model also known as RAD
two applications. model.
 An API is the middle-man which is used to retrieve  Using microservices for software development makes it
information or perform an operation required by the possible to develop deliver and deploy core functionalities
consumer , this is known as an “API call” which when that are independent of each other in a much more robust,
completed by the information or operation provider is efficient and at a faster pace as compared to the traditional
delivered back to the consumer, this is known as a monolithic applications.
“response” to the API called by the consumer.
 An API also makes it so that the API call workings are not  Monolithic Architecture :
needed to be known by the consumer i.e. the resource  Monolith in regards to software means all in one
retrieval and origin are hidden. piece. Monolith also means something that is way
 API usage within an organization also ensures that the too big or unable to be changed which in the context
information and resources within the organization are of software translates to something that is tightly
shared while monitoring and controlling access to the coupled.
same, which is an important aspect from a security  Monolithic architecture is the traditional way of
standpoint. developing a software in which all the components
albeit independent or dependent by their core
functionality are integrated in a way everything is
connected and dependent.

IJISRT22JUN1339 www.ijisrt.com 1655

Volume 7, Issue 6, June – 2022 International Journal of Innovative Science and Research Technology
ISSN No:-2456-2165
 Tightly Coupled :  Business Logic : This layer holds the source code
 It is a system design and computing concept where all responsible for all the operations that the application is
hardware and software components are linked together in designed to perform and then gives results back to the
such a manner that each component is dependent upon User Interface.
each other.  User Interface: UI is a representational layer by which a
 An application based on tightly coupled architecture user interacts with the application and it also displays
promotes interdependent code. results of an operation or task completed by the
 Application functionalities based on this type of concept application’s business logic.
are dependent on each other regardless of the aim of the
functionality. In monoliths the database is connected to a data access
 Monolithic applications are excellent examples of tightly layer which is connected to business logic which is then
coupled system design. finally connected to the user interface.

 Loosely Coupled : Since there is the above-mentioned connection flow,

 This is a software design and computing concept which is alternate layers do not communicate with each other
essentially the exact opposite of tightly coupled system independently, as they are always dependent on the layer
design and computing concept. between them. i.e. The User Interface can not connect with
 In a loosely coupled architectural concept the components the data access layer without not first connecting to the
of a system are connected in an independent manner and business logic layer.
also each individual component in a loosely coupled
architectural concept has a single function.  Advantages:
 Simplicity of development: The monolithic approach is
B. Phase 2: Comparative Analysis the traditional way of building applications. All source
code is located in one place which can be quickly
understood in early stages.
 Offline Applications can be developed using monolithic
architecture.
 Simplicity of debugging: The debugging process is
simple because all code is located in one place. You can
easily follow the flow of a request and find an issue.
 Hassle free deployment: Only one deployment unit (e.g.
jar file) should be deployed. There are no external
dependencies that are required to be plugged. In cases
when UI is packaged with backend code you do not have
any breaking changes. Everything exists and changes in
one place.
 Simplicity in onboarding new team members: As all
the source code is located in one place. New team
members can easily get familiar with the application.
 Low cost in the early stages of the application. All
source code is located in one place, packaged in a single
deployment unit, and deployed. There is no overhead
neither in infrastructure cost nor development cost.
Fig1:- Architectural Layout Comparison Even though monoliths present to be a simple and
effective software architectural decision, some serious
 Monolithic Architecture: drawbacks/disadvantages which are listed below present
A typical single instance of monolithic architecture themselves as the monolith grows in size.
consists of four components :
1. A Database.  Disadvantages:
2. Database Access Layer.
 Slow speed of development: For a monolith that contains
3. Business Logic. a lot of components. If each component in this monolith
4. User Interface(UI). is covered with tests that are executed for each code pull
request. Even for a small change in a source code, one
 Database : This usually consists of many tables in a could be waiting a long time (e.g. a few hours) for the
relational management system. request to succeed. If for some reason the request fails one
 Database Access Layer : This layer of the architecture is would have to wait all over again for it to succeed.
responsible for connecting the rest of the application to
the database to perform CRUD operations.

IJISRT22JUN1339 www.ijisrt.com 1656

Volume 7, Issue 6, June – 2022 International Journal of Innovative Science and Research Technology
ISSN No:-2456-2165
 Spaghetti code: As monoliths increase in size it is Currently JSON is the most preferred way of delivering
observed that more often than not there will be some data as it is readable by both humans and machines.
spaghetti code in at least a few places within the project.
As a result, the system becomes harder to understand RESTful APIs that are based on HTTP have the
especially for new team members. following characteristics :
 Code ownership cannot be practiced: As the system is  An URI, such as http://example.restapi.com/
growing. The next logical step is to split responsibilities  Standard HTTP methods(GET, POST, PUT and
between several teams. However, since monoliths have DELETE).
tightly coupled code there are no boundaries between  A media type (e.g. application/json, application/xml,
those services. One team can affect another. application/vnd.github.v3+json, etc.).
 Code reusability: A block of code once created in  An endpoint at the end of URI, such as /api/books.
monoliths is tailored to fit the business requirements for
that application which makes having reusable code highly RESTful APIs use microservice architecture.
unlikely.
 Lengthy Testing: Even a small change can negatively In REST API whenever there is a function or task that
affect the system. As a result, the regression for full needs to be executed which is done by a user interacting with
monolithic service is required. the user interface. An API call is triggered consisting of an
 Performance issues: As a single database is used for all URI with an endpoint which is then redirected to the specific
the services. Performance issues are quite evident even microservice.
after various types optimization (e.g. database query
optimization).The size of the application can slow down  Microservice Architecture:
the start-up time. A microservice architecture consists of many small
 Inevitable infrastructure costs: To make sure the (micro)services; each of these services can have their own
performance issues are mitigated to the maximum the independent databases if the application structure demands it.
obvious approach is to scale the whole infrastructure to
support the heavy work-loads and operations, to achieve In microservice architecture each microservice is
this upscaling of infrastructure additional costs will be responsible for a single function and if one of these functions
incurred. is dependent on another the dependent microservices
 Legacy technologies: Upgrading and migrating the communicate with each other to perform the required task
technologies originally used in development is difficult while maintaining independent state from other non-related
and can often prove just outright impossible due to the microservices.
tightly coupled nature of the codebase of used
technologies. Not being able to upgrade or migrate to  Advantages :
newer versions or technologies imposes a huge risk factor  Loosely coupled code: The biggest advantage of
on longevity of the monoliths. microservices is that each service is independent except
 Rigidity: As monoliths grow and age, newer for communication points. As a result, each component
technologies/tools that might be more efficient cannot be can be developed by a different team.
adopted due to the tightly bound codebase and nature of  Limited service scope: Since services are usually small,
monoliths. they are usually easier to understand.
 Problems with deployment: Even a minor change  Simple Debugging: debugging process is simple in the
requires the whole redeployment of the monolith which scope of a single service.
causes application downtimes which then in turn causes  Flexibility: A service can operate on its own database
revenue loss as well as data loss in the sense that no new which can be RDBMS, NoSQL, both or none of them.
data is being added as the application is down for Also, services can be written in different programming
redeployment. languages.
Due to these factors continuous deployment of the monoliths  Code reusability: A created service has very little
is not viable. business logic constraints so the service can always be
used in other applications with just a little bit of tweaking
 REST API Architecture: which makes development of related applications much
APIs based on web services that follow the REST faster.
architectural constraints are called RESTful APIs.  Scalability: This is one of the major advantages of this
architecture as components can be scaled upwards or
RESTful APIs transfer the representation of the state of downwards depending on the load and optimized
the resource to an endpoint when a request is made by a independently. Performance characteristics do not have
client. This representative information also referred to as limits. For example, an application can have few instances
resource/data can be delivered by many formats via HTTP, of one service and many instances of other service.
namely JSON (javascript object notation), HTML, PHP,  Cost-effective: A RDBMS database can be replaced by a
Python or just simple plain text. single purpose NoSQL database for a particular service.
Because of that, microservices can also be cost-effective
for large applications.

IJISRT22JUN1339 www.ijisrt.com 1657

Volume 7, Issue 6, June – 2022 International Journal of Innovative Science and Research Technology
ISSN No:-2456-2165
 Modularity: Microservices are small. Migration to a new III. CONCLUSION
platform version can be very simple. For instance,
migration from a lower Java version to a higher version. In this paper REST API application is compared with
 High speed of development: A lot of frameworks are the traditional monolithic application via a comparative
optimized to be used as microservices (e.g. Spring Boot). analysis of their architectural styles to determine if one is
Services are small, consequently, the execution is fast. better than the other. To which it can be concluded that it is
 Efficient and fast deployments: Bugs and features can viable to adopt a REST API based application if at all an
be fixed and deployed in a single service. The deployment application is to be complex and/or is required to have
time is small due to the size of the services. Since each scalability to integrate future developments and features,
service is designed to perform a specific function, rapid whereas if an application is supposed to be simple and
deployment of features and changes is possible. lightweight, developed in regards to a very specific subject
domain which will have minimal to low scalability
 Disadvantages : requirements in the future only then the monolithic
 Debugging: While working in the scope of a single application seems a viable choice.
component, everything is simple. However, the
architecture as a whole is complex. A single request can REFERENCES
operate on multiple services, tracking this request during
debugging can sometimes be difficult. [1]. REST. [Online]:
 Testing: Testing is challenging because of the distributed https://en.wikipedia.org/wiki/Representational_state_tr
components. ansfer
 Deployment: Services can be deployed separately. [2]. Microservice vs Monoliths. [Online]:
However, they usually communicate somehow. https://www.mulesoft.com/resources/api/microservices
Interaction contracts between services have to be strictly -vs-monolithic
defined. A change in one service should not break other [3]. Anton Kharenko. Monolithic vs. Microservices
services. Architecture. [Online]:
 Cross-cutting concerns: Security, logging, monitoring, https://articles.microservices.com/monolithic-vs-
configuration, etc. should be implemented in each service. microservices-architecture-5c4848858f59
[4]. Oleksii Dushenin. How To Understand Microservices
C. Phase 3 : Discussion Architecture. [Online]: https://datamify.medium.com
Whenever monolith applications grow in size and [5]. Carlos. Migrated from monoliths to microservices.
complexity : [Online]: https://www.kambu.pl/blog/companies-that-
 There often arises a situation where no single developer migrated-from-monolith-to-microservices/
(or group of developers) understands the entirety or
working of the application.
 Limited to non-existent component reusability is
observed.
 Scaling monolithic applications is costly and challenging.
 Repeated deployment of monolithic applications causes
revenue and data loss.
 By definition, monolithic applications are implemented
using a single development stack of technologies, this
hampers the integration of using a tool that will be better
suited for the job which is outside the development stack.

When REST API application is considered for scalable

and complex applications instead of monolithic application
following points are evident:
 Achieving scalability is easier in REST API applications.
 Relative costs of scaling are also lower.
 Constant deployments of components and updates is only
possible here without sacrificing major revenue and data
loss as services not being updated are not affected.
 Understanding services involved is much simpler for new
developers as each service(or small group of services) is
designated with a single function.

Some Companies that migrated from monoliths to

microservices realizing that monoliths are not scalable are
Amazon, Netflix, Ebay, Uber.

IJISRT22JUN1339 www.ijisrt.com 1658