What is REST and what are RESTful designs?

NOTE- This post assumes that you have a basic idea of HTTP and web services.

While making any web service we often come across the terms REST and RESTful. We all get a basic idea of what REST is while working on web services, for example, it is related to HTTP and has resources or something of that sort. So today let’s learn what REST actually is then we can easily understand what we have actually been doing while building RESTful web services.( apparently :P)

What is REST?

REpresentational State Transfer (or REST) is a set of design principles for making network communication more scalable and flexible. It revolves around resources where every component is a resource and a resource is accessed by a common interface using HTTP standard methods. Now you must be wondering what is a resource?

A resource is anything that’s important enough to be referenced as a thing in itself. It generally refers to something that can be stored on a computer /server and is represented as a stream of bits. Each resource can be accessed by one or more URIs (Uniform Resource Identifier) and can be modified using HTTP methods (GET, PUT, POST, DELETE, etc.)

REST is basically an architectural style for web services that defines a set of constraints and properties based on HTTP. The above statement does seem to imply that HTTP and REST are related but actually they are mutually exclusive. REST just uses HTTP protocol for data communication but is not dependent on it.

The term REST was coined by Roy T. Fielding in 2000, in his PhD dissertation Architectural Styles and the Design of Network-based Software Architectures. Fielding tried to understand the underlying principles that made the World Wide Web (or www) more successful than other competing internet protocols and incorporated them in a framework for network communication. This framework, which was “web-like”, was termed as REST by Fielding. Therefore, REST is a generic set of principles not specific to the Web. It can be applied to other kinds of networks such as embedded systems, etc.

REST is not a protocol since it does not prescribe any implementation details. It is rather a convention we follow to make our communication more scalable, flexible and most of all, more “web-like’.

Architectural Constraints

Fielding’s dissertation outlines a number of architectural constraints that a system must satisfy to be considered RESTful. (Again we come across the term RESTful without knowing what it is, XD)

Any system or service that is REST-compliant (follows the REST convention) is termed as RESTful.

There are six main constraints that need to be followed to make a service truly RESTful. These are as mentioned below :-

1. Client–server architecture

In the REST architectural style, the implementation of the client and the implementation of the server can be done independently without them knowing about each other. This means that the code on the client side can be changed at any time without affecting the operation of the server, and vice-versa.

The server and client can be kept modular and separate if they know what format of messages (or requests) they need to send to communicate with each other. Separating the user interface concerns from the data storage concerns, we improve the flexibility of the interface across platforms and improve scalability by simplifying the server components. Additionally, the separation allows each component to evolve independently.

By using a REST interface, different clients can hit the same REST endpoints, can perform the same actions, and will receive the same responses.

2. Stateless

Stateless does not mean that servers and clients do not have state, it simply means that they do not need to keep track of each other’s state. When a client is not interacting with the server, the server has no idea of its existence. The server also does not keep a record of past requests. Each request is treated as a standalone and contains all the information necessary for its servicing.

An example of a stateless protocol is HTTP meaning that each request message can be understood in isolation.

On the contrary, a traditional FTP server conducts an interactive session with the user. During the session, a user is provided a means to be authenticated and set various variables (working directory, transfer mode), all stored on the server as part of the user’s state. Therefore it’s not stateless.

3. Uniform interface

The “uniform interface” constraint ensures that there is a common language between servers and clients that allows each part to operate and evolve independently. This is achieved through 4 sub-constraints as explained below.

I. Identification of resources

The first sub-constraint of “uniform interface” affects the way that resources are identified. Each resource must be uniquely identified by a stable identifier.

A “stable” identifier means that it does not change across interactions, and it does not change even when the state of the resource changes.

If a resource does get moved to another identifier, the server should give the client a response indicating that the request was bad, and give it a link to the new location of the resource.

For example, the web uses URI to identify resources, and HTTP as its communication standard.

II. Resource manipulation through representations

The second sub-constraint of “uniform interface” says that the client manipulates resources through sending representations to the server–usually a JSON object containing the content that it would like to add, delete, or modify. In REST, the server has full control of the resources, and is responsible for making any changes. When a client wishes to make changes to resources, it sends the server a representation of what it would like the resulting resource to look like. The server takes the request as a suggestion, but still has ultimate control.

For example, whenever the user wishes to create or update something in his web service he sends HTTP a POST or PUT request to do the same respectively. The server sends back a response indicating whether the requested action was completed, or if there was a problem. In a non-REST world, the client may literally be sending instructions for operations such as adding a new line on the page or changing the title of the page, etc. instead of simply sending a representation of what it would like the final product to look like.

III. Self-descriptive messages

Self-descriptive messages are another constraint that ensures a uniform interface between clients and servers. A self-descriptive message is one that contains all the information that the recipient needs to understand it. There should not be additional information in a separate documentation or in another message.

For example-

When a user types http://www.example.com in the address bar of their web browser, the browser sends the following HTTP request:

GET / HTTP / 1.1
Host: www.host_name.com

This message is self-descriptive because it told the server what HTTP method was used, and the protocol that was used (HTTP 1.1).

The server may send back a response like this:

HTTP/1.1 200 OK
Content-Type: text/html
<!DOCTYPE html>
<html>
<head>
<title>Home Page</title>
</head>
<body>
<div>Hello World!</div>
<a href= “http://www.site_name.com”> Check out this site! </a>
</body>
</html>

This message is self-descriptive because it told the client how it needs to interpret the message body, by indicating that Content-type was text/html. The client has everything it needs in this single message to handle it appropriately.

Imagine an alternative method of communication where the server sent binary code in one response, and then sent a separate response telling the client how to interpret the binary code–whether it is an image or a code snippet. If the two responses had somehow arrived out of order, or if a third response was inserted between them, then the client may be confused about how to interpret the responses properly. This is the reason REST constraints us to send self descriptive messages from both the client and server end.

IV. Hypermedia and HATEOS

Hypermedia, an extension of the term hypertext, is a nonlinear medium of information that includes graphics, audio, video, plain text and hyperlinks.

Hypermedia, while sounding complex, is really just saying that we embed links within our documents. Further, HATEOAS (Hypermedia as the Engine of Application State) implies that these links are the mechanism for exploring and interacting with / manipulating the resources within our application.

If system follows all the above sub-constraints, it is said to have a uniform interface. This is one of the most important properties of REST, as it allows the clients to intelligently adapt to changes. A server can change the underlying implementation without breaking all the clients that interacted with it, because each interaction is self-contained, identifiers do not change when the underlying state or implementation changes, and hypermedia gives clients instructions for state transitions that it can do next.

4. Cacheability

In computing, a cache is a hardware or software component that stores data so future requests for that data can be served faster; the data stored in a cache might be the result of an earlier computation, or the duplicate of data stored elsewhere. The process of storing data in a cache is termed as Caching.

As mentioned above, caching is a feature that makes accessing data faster in future requests. Server responses should be labelled as either cacheable or non-cacheable in order to allow clients to only cache cacheable response and thus improving system scalability, flexibility and speed.

5. Layered system

There can be more components than just servers and clients in the system. This means there can be more than one layer in the system. However, each component is constrained to only see and interact with the very next layer.

A client cannot ordinarily tell whether it is connected directly to the end server, or to an intermediary along the way. Intermediate servers (or intermediate layers) may improve system scalability by enabling load balancing and by providing shared caches. They may also enforce security policies.

Examples of intermediate layers are Proxy and Gateway.

6. Code on demand (optional)

This is the only constraint that is optional. It refers to the ability of server to send executable code to the client to temporarily extend or customise it’s functionality. This is what happens in HTML’s <script> tag. When the HTML document is loaded, the browser automatically fetches the JavaScript from the server and executes it locally.

So to conclude, we can say that any network that follows Fielding’s constraints can be termed as RESTful. A RESTful system is meant to be flexible for different use cases, scalable to accommodate a large number of users and components, and adaptable over time.

The World Wide Web, whose analysis helped Fielding coin the term REST, also fails to follow some of these constraints at some points. This shows that REST is just a theoretical design and is just a convention (NOT a protocol). Therefore, it’s totally the user’s decision to follow REST constraints or not, but considering it’s benefits, one should follow it (not necessary to follow it strictly) in order to improve his system and making client-server interaction more scalable and flexible. Finally, there are other protocols and conventions too, like SOAP protocol, so examine carefully the need of your system and choose your protocol and/or convention wisely.

I hope this blog gave the readers a basic understanding of the terms REST and RESTful and what they have been actually doing while building RESTful services.

Enjoy your REST of the day !