REST is an acronym for Representational State Transfer.
REST is a style of software architecture for distributed systems
such as the World Wide Web.
Rest is created to serve as the guiding framework for the web
REST can be seen as a post hoc description of the features of the
World Wide Web.
The original description was used to develop the HTTP/1.1
The architecture consists of clients and
servers, requests and responses.
Requests and responses are built around the
transfer of representations of resources.
Clients contain representations, servers the
resources (concepts) themselves.
How REST works?
Give every “thing” an ID(URI)
Link things together
Use standard methods(HTTP etc)
Resources with multiple representations
URI(uniform resource identifier)
Resources are referred to individually with a
universal resource identifier, such as the URL
used for Web addresses.
a uniform resource identifier (URI) is a string of
characters used to identify a name of a web
Such identification enables interaction with
representations of the web resource over a
network (typically the World Wide Web) using
specific protocols. Schemes specifying a concrete
syntax and associated protocols define each URI.
An URI identifies a resource either by location, or
a name, or both. A URI has two specializations
known as URL and URN.
All requests made to connectors must contain
all the information necessary to understand
that request without depending on any
previous request. This contrasts with the way
between sessions. With REST, all messages
must include all information necessary to
understand the context of an interaction.
A client can be either transitioning between
states or be at rest.
A client is considered to be transitioning
between states while one or more requests are
The representation of the client state contains
links that can be used to initiate new state
A client in a rest state is able to interact with its
A client at rest creates no load on the servers
or the network.
A client at rest consumes no per-client storage
on the servers.
The REST architecture describes the following
constraints to implement this concept:
• Uniform interface
• Layered system
• Code on demand [optional]
Clients are separated from servers by a
uniform interface. So we have a separation
– Clients are concerned with the presentation to
the user and the application state
– Servers are concerned with data storage,
domain model logic etc.
improves UI portability
enables multiple organizational domains
No client context is stored on the server
Each request from any client contains all of the
information necessary to service the request,
and any state is held in the client.
The server can be stateful, this constraint
merely requires that server-side state be
addressable by URL as a resource.
Clients are able to cache responses.
Responses must, implicitly or explicitly, define
themselves as cacheable or not.
reduces average latency
+ improves efficiency
+ improves scalability
A uniform interface between clients and
simplifies and decouples the architecture.
This enables each part to evolve independently.
A client cannot ordinarily tell whether it is
connected directly to the end server, or to an
intermediary along the way.
Layers providing load balancing, security or
shared caching can be added or removed very
easily this way.
+ shared caching
+ improves scalability
+ legacy encapsulation
+ load balancing
Code on demand (optional)
Servers are able temporarily to extend or
customize the functionality of a client by the
transfer of executable code. Examples of this
may include compiled components such as
Java applets and client-side scripts such as
With RESTful design, Web services can be
seen as simply a means of publishing
information, components and processes to
make them accessible to other users and
REST requires less client-side software than
do other approaches, because a single,
standard browser can access any application
and data resource.
Offers possibilities for thin client development as less client
code is required.
Does not require explicit resource discovery mechanism due
Scalable architecture compared with those that require
Caching promotes network efficiency and fast response
Software versioning benefits including support of document
type evolution such as HTML and XML without impacting
backward or forward compatibility.
Resource extensibility, allowing support for new content
types without impacting existing and legacy content types.
HTTP as a uniform interface presents
technical challenges for real time
asynchronous events to a thin client or
browser based application.
Managing URI Namespace can be
Lacks supporting software tools
Can impact network performance by
encouraging more frequent client-server
requests and responses.