Architectural Constraints of REST


The term REST, (Representational State Transfer) was introduced in way back in year 2000, by Roy Fielding in his doctoral dissertation at UC Irvine[1]. Though it is about 16 years ago, still it’s importance is more or less the same. REST introduces an architectural style for web applications.

REST is tightly coupled, and embraces the potential of HTTP. Because of that it has become more popular in web application domain. REST see a web application as a virtual state-machine where states are different web pages; progressing user from one state to another through links; and going to another state.

REST web application with state transitions

To call be a web application RESTful, it needs to comply certain constraints. Following those constraints also helps web application to have desirable non-functional properties as well.

Architectural Constraints

Decoupled client-server interaction

There should be a uniform interface to separate client and server, which helps to achieve separation of concerns. Client has no need to store data, such that client is portable. On the other hand, server does not worry about keeping user state, so server-side can be scaled. In RESTful architecture server and clients should be able to use different technologies to develop separately.


Going further with client-server architecture, the server should not keep client context between requests. Each request from client should include all the information necessary to serve that request. Session state is held at client side. Once session data is received, the service can transfer that to another service.

Each state of application contains the links for client to choose the next state transition.


The client may connect to intermediate layers, which might not aware before-hand. So those layers can enforce security, do load balancing, provide caching etc.


Response from server can be cached at client side and at intermediaries, as defined by HTTP response. Cache-Control Header plays a key role in that behavior [2].

Extensible through code on demand

This is an optional requirement. Server can send executable code to client side to customize the functionality of the client. Client-side scripts such as JavaScript can be taken as an example.

Uniform Interface

This a basic requirement of a RESTful service and helps to make decoupled client-server interaction.

  • Identification of resources

Server can use requests to identify resources separately (eg: URI), and returns the representation of that resource to client (as HTML, XML or JSON).

  • Manipulate the resource through its representation

The representation send by the server is enough for a client to manipulate (update, delete) that resource.

  • Self-descriptive messages

Information included in a message contains adequate information on how to manipulate that message.

  • Hypermedia as the engine of application state (HATEOAS)

“Hypermedia, an extension of the term hypertext, is a nonlinear medium of information which includes graphics, audio, video, plain text and hyperlinks” [3]

So clients can only make transitions, through actions that are dynamically identified within hypermedia by the server. There are no standard format to represent links in a hypermedia, but there are few popular ones [4].

Architectural Properties

The constraints helps you to achieve following properties;

  • Performance
  • Scalability
  • Simplicity of interfaces
  • Modifiability
  • Visibility
  • Portability
  • Reliability

Web service APIs that comply with REST architectural constraints are called RESTful APIs [5].








Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s