Representational State Transfer
Tricode Professional Services
"The motivation for developing REST was to create an
architectural model for how the Web should work, such that
it could serve as the guiding framework for the Web
REST has been applied to describe the desired Web
architecture, help identify existing problems, compare
alternative solutions, and ensure that protocol extensions
would not violate the core constraints that make the Web
- Roy Fielding
• 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
“Why should I care?”
• The beauty of the web is it’s simple structure.
• We may want to learn from this so we may
choose to implement this design in our own web
• Since we are looking back at the basics of the
World Wide Web, it is good to look back at what
the internet is and came to be.
WWW vs. internet
• The internet includes all connected networks.
• The World Wide Web is the part of the internet
that uses the HTTP protocol.
• Representational State Transfer is a software
• REST was developed along the HTTP/1.1 protocol.
And HTTP/1.1 adheres to it.
REST concept (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.
REST client and server
REST concept (2)
• 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
REST client application
Representations of resources
Links to start a
REST concept (3)
• A client in a rest state is able to interact with its
• A client at rest creates no load on the servers or
• A client at rest consumes no per-client storage on
REST at rest
The REST architecture describes the following six
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 of concerns:
– Clients are concerned with the presentation to the user
and the application state
– Servers are concerned with data storage, domain
model logic etc.
Apply separation of concerns: client-server
+ improves UI portability
+ simplifies server
+ enables multiple organizational domains
• No client context is stored on the server between requests.
• Each request from any client contains all of the information
necessary to service the request, and any state is held in the
• The server can be stateful, this constraint merely requires
that server-side state be addressable by URL as a resource.
Constrain action to be stateless
+ simplifies server - degrades efficiency
+ improves scalability
+ improves reliability
• Clients are able to cache responses.
• Responses must, implicitly or explicitly, define
themselves as cacheable or not.
• A uniform interface between clients and servers
simplifies and decouples the architecture.
This enables each part to evolve independently.
Guiding principles of the interface
Identification of resources
Individual resources are identified in requests. The resources themselves are
separate from the representations that are returned to the client.
Manipulation of resources through representations
The representation of a resource, including any metadata attached, has
enough information to modify or delete the resource on the server.
Each message includes enough information to describe how to process the
Hypermedia as the engine of application state
If it is likely that the client will want to access related resources, these should
be identified in the representation returned.
• 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.