× Please, log in to give us a feedback. Click here to login

You must be logged to download. Click here to login


MrBool is totally free and you can help us to help the Developers Community around the world

Yes, I'd like to help the MrBool and the Developers Community before download

No, I'd like to download without make the donation


MrBool is totally free and you can help us to help the Developers Community around the world

Yes, I'd like to help the MrBool and the Developers Community before download

No, I'd like to download without make the donation

Introduction to REST

In this article we shall see an overview of REST (REpresentational State Transfer) and some of its features.

REST is an acronym and stands for REpresentational State Transfer. REST was first described by Roy Fielding in his PhD thesis, published in 2000. Over the years it has gained acceptance as a better and easier alternative to SOAP and WSDL (Web Service Description Language).

REST Overview

REST is neither a framework nor a technology.


“REST is an Architectural Style built on certain principles using the current HTTP web fundamentals”. The above definition can be put in the following simple diagram:

Simple diagram

Figure 1: Simple diagram

Here we come across two words “Architectural style and Fundamentals”. Let’s see what they mean:

Architectural style

In the software world we have three terminologies which might confuse us they are: Architecture pattern, Architectural style and Design pattern. Following we have detailed the differences between the three:

  • Architecture pattern: An Architectural Pattern is a way of solving a recurring architectural problem. MVC, for instance, solves the problem of separating the UI from the model. Sensor-Controller-Actuator is a pattern that will help you with the problem of actuating in face of several input senses.
  • Architectural Style: An Architectural Style, on the other hand, is just a name given to a recurrent Architectural Design. Contrary to a Pattern, it doesn't exist to "solve" a problem. Client/server, Main program & subroutine and Abstract Data Types / OO, Service Oriented Architecture (SOA) does not solve a problem. They are just concepts or names given. Also, a single architecture can contain several architectural styles, and each architectural style can make use of several architectural patterns.
  • Design Pattern: A design pattern is a solution at code level; it talks about classes, functions and logic of how the code flows.


Fundamentals are leveraged to create REST services. There are basically five fundamentals or principles:

  • Resources: Application state and functionality are abstracted into resources.
  • Unique Identifier: Every resource is uniquely addressable using a universal syntax for use in hypermedia links.
  • Uniform Interfaces: All resources share a uniform interface for the transfer of state between client and resource.
  • Representations: A representation captures the current or intended state of a resource.
  • Stateless: REST recommends server not to save the state of each client request. All information needed for request to be handled should be included in request. Server does not need to save information related to client, so the system can respond flexibly to the increase of the number of clients.

We also need to understand a one more jargon called constraint which is often associated with REST. According to the REST thesis by Roy Fielding, a constraint is a rule that induces one or more software architecture properties. A group of constraints is called a style. The REST style is a group of six major constraints that induce the various properties needed for the Web. In order for architecture to be viewed as REST architecture, it must satisfy all of these constraints. They are:

  • Client/server
  • Stateless communication
  • Caching
  • Uniform Interface
  • Layered System
  • Code On demand

REST Goals

Roy Fielding defines the non-functional property set that he uses to evaluate various architectural styles against one another:

Architectural Properties

Figure 2: Architectural Properties

A REST based system should exhibit the above architectural properties or goals. An explanation for these is as follows:


The term performance means different things to different people. To end users, high performance means that when they click on a link, or click on a buy button on an e-store, they get immediate results; to developers, it means solving the typical problem of service availability and supporting architectures that are scalable.

REST can support the Performance goal by using caches to keep available data close to where it is being processed. It can further help by minimizing overhead associated with setting up complex interactions by keeping each interaction simple and self-contained (as a request-response pair).


Scalability, in the context of the Web, means to consistently provide service regardless of the increase or decrease of web users.

REST-style architectures support load balancing across service instances via the Layered System and Uniform Interface constraints. This can be further simplified through the Stateless constraint, which structures interactions as request-response pairs that can each be handled by services independently of other requests. There is no need to keep directing the same service consumer to the same service instance or to synchronize session state explicitly between service instances; the session data is contained in each request.


By separating the functionality within components in a system, we can induce the simplicity to the architectural styles. If functionality can be allocated such that each component is less complex, then they will be easier to understand and implement.

The major contribution of REST to Simplicity is the Uniform Interface constraint. Overall system architecture is simplified and the visibility of interactions is improved. The functionality encapsulated by services is abstracted from the underlying interface implementation.


The requirements for any architecture are bound to change over time. Modifiability represents the ease at which changes can be incorporated in the architecture.

Modifiability in REST-style architecture is further broken down into the following areas:

  • Evolvability - Represents the degree to which a component can be re-factored without impacting other parts of the architecture.
  • Extensibility - The ability to add functionality to the architecture (even while solutions are running)
  • Customizability - The ability to temporarily modify parts of a solution to perform special types of tasks
  • Configurability - The ability to permanently modify parts of an architecture
  • Reusability - The ability to add new solutions to architecture that reuse existing services, middleware, methods, and media types, without modification.

Modifiability is particularly important for larger distributed architectures where it is not possible to redeploy the entire environment every time an architectural improvement is made.


Visibility refers to the ability of a component to monitor or mediate the interaction between two components. REST supports visibility through Uniform Interface constraint. Visibility can enable:

  • Improved performance via shared caching of interactions,
  • Scalability through layered services,
  • Reliability through reflective monitoring
  • Security by allowing the interactions to be inspected by mediators


Portability represents the each with which a system can be moved from one deployed location to other.

In REST architecture style, the client/server constraint helps improve the UI portability.


Reliability of a distributed architecture is the degree to which its solutions and services (and underlying infrastructure) are susceptible to failure. An architecture style can improve the reliability by avoiding single points of failure, using failover mechanisms, and relying on monitoring features that can dynamically anticipate and responds to failure conditions.

REST Tools

Following diagram lists the tools used for development of REST architecture style:

Rest Tools

Figure 3: Rest Tools

REST Benefits

Maximizes reuse

  • uniform resources having identifiers increases reuse potential

Minimizes coupling to enable evolution

  • uniform interface hides all implementation details supporting low coupling
  • hypertext allows late-binding of application control-flow, hence leading to reduction in attempted inappropriate accesses and resultant errors.
  • gradual and fragmented change across organizations

Eliminates partial failure conditions

  • server failure does not perplex client state
  • shared state is recoverable as a resource, leading to improved fault tolerance

Scales without bound

  • services can be layered, clustered, and cached leading to improved scalability.


In this article we saw an introduction to REST architecture. Hope you liked it.

I''m a full stack developer with around 10+ yrs of experience. I enjoy writing technical articles on upcoming technical trends.

What did you think of this post?
To have full access to this post (or download the associated files) you must have MrBool Credits.

  See the prices for this post in Mr.Bool Credits System below:

Individually – in this case the price for this post is US$ 0,00 (Buy it now)
in this case you will buy only this video by paying the full price with no discount.

Package of 10 credits - in this case the price for this post is US$ 0,00
This subscription is ideal if you want to download few videos. In this plan you will receive a discount of 50% in each video. Subscribe for this package!

Package of 50 credits – in this case the price for this post is US$ 0,00
This subscription is ideal if you want to download several videos. In this plan you will receive a discount of 83% in each video. Subscribe for this package!

> More info about MrBool Credits
You must be logged to download.

Click here to login