1 REST – The Architectural Style

REST – THE ARCHITECTURAL STYLE

M. VAQQAS

July 2014

© M VAQQAS 2014
2 REST – The Architectural Style

TABLE OF CONTENTS

Table of Contents .................................................................................................................................... 2

Introduction ............................................................................................................................................ 3

What is REST ........................................................................................................................................... 3

REST Architectural Constraints ............................................................................................................... 3

Client-Server ....................................................................................................................................... 4

Stateless .............................................................................................................................................. 4

Cacheable............................................................................................................................................ 5

Layered System ................................................................................................................................... 6

Code on Demand ................................................................................................................................ 7

Uniform Interface ............................................................................................................................... 7

Advantages and Disadvantages of REST ................................................................................................. 8

Advantages ......................................................................................................................................... 8

Simplicity ......................................................................................................................................... 8

Easy Discovery................................................................................................................................. 9

Performance ................................................................................................................................... 9

Scalability ........................................................................................................................................ 9

Search Engine Friendly .................................................................................................................... 9

Disadvantages ..................................................................................................................................... 9

No Server Initiated communication ................................................................................................ 9

Extensibility ..................................................................................................................................... 9

Security ......................................................................................................................................... 10

Conclusion............................................................................................................................................. 10

References ............................................................................................................................................ 10

About the author .................................................................................................................................. 10

© M VAQQAS 2014
3 REST – The Architectural Style

INTRODUCTION

REST stands for Representational State Transfer which was introduced by Roy Fielding in 2000. It has
been more than a decade since REST was introduced. But it is only recently that REST based web
services started to gain popularity. There has been a visible shift in the industry from SOAP and
WSDL based services to REST based services. Industry leaders like Facebook, Google, Yahoo and
Twitter have shifted to REST based services. Reasons for this shift vary. It may be due to the
simplicity of REST based services. Or, it may be to avoid proprietary software and standards which
are required to build and host SOAP based services. Clearly REST has become industry favorite for
developing web services and it is important for the web developers to have a clear understanding of
REST.

There is a lot of information available on the Internet about REST. Some of this information is no
doubt good but there is no lack of inaccurate and sometimes misleading sources as well. This paper
is an attempt to explain REST in a clear and easy to understand manner. Please note that the
objective of this paper is to describe REST the architectural style. The implementation of REST is not
in the scope of this paper. A separate paper about the implementation of RESTful web services using
HTTP is in queue.

WHAT IS REST

REST is an architectural style for distributed hypermedia based applications. It contains a set of
architectural constraints which are applied to components, connectors, and data elements within a
distributed hypermedia system. REST might be more suitable for web applications and services
however it is not specific to the web. Any distributed system can be based on REST. World Wide
Web itself can be considered as an example of REST based systems.

REST is not a standard or a protocol. It is also a misconception that only HTTP can be used to build
RESTful services. This is true that currently mainly HTTP is used to implement REST services.
However, REST is not dependent on any protocol, language or platform. Any other application level
protocol which has a uniform interface and allows you to implement REST constraints can be used to
implement REST based applications.

REST ARCHITECTURAL CONSTRAINTS

The purpose of these constraints is to provide performance, scalability, simplicity, modifiability,

visibility, portability, and reliability. An application or a service is considered REST based or
“RESTful” only if it complies with these constraints. Only Code on Demand constraint is optional rest
are mandatory to be followed.

The architectural constraints in REST are:

1. Client-Server

© M VAQQAS 2014
4 REST – The Architectural Style

2. Stateless
3. Cacheable
4. Layered System
5. Code on Demand
6. Uniform Interface

CLIENT-SERVER

REST demands a Client-Server architecture style. A server offers the resources and a client can
request these resources. Roles of a client and a server are never reversed. That is, a server can never
initiate a conversation with a client or a client cannot respond to a request. Client-Server constraint
provides a separation of concern between client and server. This allows both client and server to
evolve independently which means a better modifiability. As the service is centrally located it
improves the maintainability and security of the server.

STATELESS

Each request is independent and contains all the information required to process it. A request does
not refer to any previous request. This way server does not have the burden of storing and
maintaining the historical data of requests. Which in turn enhances the performance of server as
now server is able to serve more requests. Due to stateless nature reliability is also improved as
failure of one request does not affect the processing of other requests. Visibility is improved as
looking at the single request gives the complete picture of the nature of the request. This makes the
job of network monitoring components like firewalls a lot easier.

In case of a state-full architecture the server is required to maintain the state for each client. Usually
the state is saved at the server memory for quick access. In case of a Load Balanced service all the
servers need access to this storage. So, this storage is moved to another server usually a database
which adds the complexity, performance and resource overheads. It is easier to load balance a REST
system as there is no burden to manage the state.

© M VAQQAS 2014
5 REST – The Architectural Style

Load balancing immensely enhances the scalability, performance and reliability of a system. As now
the contextual data related to a client-server conversation cannot be stored on the server. The client
needs to send this data with every request to the server. This can result in increased network traffic
and can add delays. However, this is a simple trade off.

CACHEABLE

Results of a request can be cached at the server, at the client or at any other component between
the server and the client. The server inserts the cache settings in each response. These cache
settings contain information like whether to cache this result or not, if yes then for how much
duration this can be cached, other criteria’s to make the cached results obsolete, etc. Components
who wish to cache these results must adhere to these settings otherwise it may result in client being
served with the obsolete response.

Please note that the caching is very different from the state management. In caching the results are
stored for a short duration and used if the same request arrives during this period. This immensely
improves the response time of a server.

© M VAQQAS 2014
6 REST – The Architectural Style

LAYERED SYSTEM

There can be other layers between client and server. Components like proxies, gateways, firewalls,
or other services can be placed between client and server. For example there can be a service on top
of a legacy service to cater to newer clients or there can be a legacy service on top of a new service
to cater to legacy clients. These intermediate components can have caching capabilities with no
effects on the client’s experience which further enhances the response time for a system.

A layered system allows for load balancing by which load on a server can be shared among several
other servers. Load balancing makes the system highly scalable. A layered system also enhances the
security as components like firewalls can be put between the client and the server.

© M VAQQAS 2014
7 REST – The Architectural Style

CODE ON DEMAND

Server can send code in the response to the client that can be executed at the client side. This
greatly enhances the capabilities of the client as features can be added to a client dynamically.
Executing code on client side takes off some of the processing load from the server and server is free
to process more requests. As the code is executing on the client itself it results in enhanced
performance. This also reduces the network traffic as now the client does not need to make requests
to server for a feature if it is locally available. Examples are Java Applets and Java Script.

This constraint can increase the complexity and reduce the visibility. Also, this might not be required
by all the applications hence this has been kept optional. This constraint can be implemented or
omitted as required.

UNIFORM INTERFACE

A Uniform Interface is central to the REST architecture. The requests have a set pattern and the
messages are transferred in a generalized format which is not dependent on the content type. That
is, no matter if the contents of message are XML, JSON or HTML the message format remains same.
A uniform interface greatly simplifies the architecture. Any server can serve to any client,
irrespective of the technology used to create them, if both communicate using this uniform
interface. It decouples the client and server and both can be implemented separately.

This uniform interface follows four principals:

IDENTIFICATION OF RESOURCES

A request can uniquely identify a resource on the server. For example in a web-based REST system
resources are categorized, given unique ID’s and directory path like URI’s are used to identify
individual resources on the server.

© M VAQQAS 2014
8 REST – The Architectural Style

MANIPULATION OF RESOURCES THROUGH REPRESENTATIONS

Representations are used to send and receive resources in messages. For example HTML, XML or
JSON can be used to represent a resource. A client has sufficient information to create, update or
delete a resource on the server if it has the representation of this resource.

SELF-DESCRIPTIVE MESSAGES

Messages are self-descriptive. That is, a message contains enough information about how to process
it. For example a request may specify the operation to be performed and media type (MIME) of the
representation it expects. Similarly a response message can specify things like the status, media type
of the representation and settings for caching the results which are required to process that
message.

HYPERMEDIA AS THE ENGINE OF THE APPLICATION STATE

Client moves from one state to another by requesting the operations dynamically identified within
the hypermedia provided by the server. A Client does not assume the availability of any operation
for a resource on the server. For example when you visit a web site an index or a home page is
presented to you. Then you click one of the hyperlinks on this page to go to other pages available on
the site and so on.

ADVANTAGES AND DISADVANTAGES OF REST

While discussing the constraints of REST we also discussed the benefits of these constraints. We saw
how these constraints when correctly followed provide improved performance, scalability,
simplicity, modifiability, visibility, portability, and reliability. However REST is not free from
limitations. These points should be considered while deciding if REST is suitable for a particular
application or not.

ADVANTAGES

SIMPLICITY

The high points of REST are its simplicity and light weight. It is easy to implement and manage a REST
system. Message formats are simple and easy to understand. Resources are identified using a
hierarchical based URI’s which are clear and straight forward.

© M VAQQAS 2014
9 REST – The Architectural Style

EASY DISCOVERY

Discovering REST services is easy due to simple directory like URI’s. User can merely look at the URL
and predict what to expect. Client is not required to have any prior knowledge about the semantics
of a REST service.

PERFORMANCE

Light weight messages, caching, Layering and statelessness provides an enhanced performance.
REST gives a good performance for medium grained resources.

SCALABILITY

Due to the simplicity, uniform interface and easy load balancing makes the REST systems highly
scalable.

SEARCH ENGINE FRIENDLY

It is easy for crawlers and robots to list out REST services as URIS follow a consistent pattern based
on standards. This is a great advantage in today’s competitive environment and this immensely
improves the visibility of the service on Internet.

DISADVANTAGES

NO SERVER INITIATED COMMUNICATION

Sometimes there is a need for a bi-directional communication. Like in case of an instant messaging
application user would want the server to send it a notification when a message arrives for the user.
REST does not support bidirectional messaging, sessions or transactions from the server. Such
requirements are implemented by requesting a server periodically and checking for availability of a
message. Such workarounds cause high network traffic and increase the work on the server.

EXTENSIBILITY

Some applications can benefit from creating custom operations or message formats. REST offers
extensibility in other forms. However as REST postulates a limited set of verbs for simplicity it is not
possible to build custom operations.

The REST interface is designed for large-grain hypermedia data transfer and may not be optimal for
other architectural interactions. Due to generality of the message format it is not possible to create
custom message formats for some resources.

© M VAQQAS 2014
10 REST – The Architectural Style

SECURITY

It does not mean that the REST systems are any less secure but the security has been left to the
implementations. Most of the REST Services use the transport level security. For example HTTP
based RESTful services rely on SSL for security. The application need to implement its own
mechanisms to have message security.

CONCLUSION

REST is a simple and easy to implement architectural style which is great for building lightweight
distributed hypermedia systems. The stress is on the resources and not on the operations or
services. That is why REST is considered a resource oriented architecture rather than as a service
oriented architecture. REST based hypermedia systems are fast, easy to maintain and scalable. But it
may not be suitable for all types of applications as it has some limitations as well. So we should have
a clear understanding of capabilities of REST before utilizing it.

REFERENCES

1. Chapter 5 of the original dissertation by Roy Thomas Fielding

http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

2. Wikipedia Page for REST

http://en.wikipedia.org/wiki/Representational_state_transfer

3. “RESTful Web Services” by Leonard Richardson, Sam Ruby

http://shop.oreilly.com/product/9780596529260.do

ABOUT THE AUTHOR

I am a Software Engineer working on web technologies for last five years and
currently employed with United Health Group. I like learning about new
technologies and writing about them. In my free time I like reading books,
wood working and watching movies.
m.vaqqas@gmail.com

© M VAQQAS 2014