What is REST?

REST (Representational State Transfer) has become popular these days because of the high need for integration what consequently makes it very important for every developer to know and understand. This article aims to give you a guidance in what rest is and how can you use it to improve your applications.

REST describes an architectural style of networked systems such as web applications. It was first introduced in 2000 in a Ph.D dissertation by Roy Fielding, one of the principal authors of the HTTP specification. REST refers to a collection of architecture constraints and principles, which some will be shown next.

Uniform Interface

The central feature that distinguishes the REST architectural style from other network based styles is its emphasis on a uniform interface between components. Components can be origin servers, gateways, proxies or user agents (browsers).

The term uniform interface is used to describe how a (small) number of verbs with well-defined and widely accepted semantics are sufficient to meet the requirements of most distributed applications. A collection of verbs is used for communication between systems. You can check the example below which uses these verbs.

REST is defined by four interface constraints: identification of resources, manipulation of resources through representations, self-descriptive messages, and, hypermedia as the engine of application state.

Identification of resources

The key abstraction of information in REST is a resource. Any information that can be named can be a resource: a document or image, a collection of other resources or even a person. REST uses a URI (unique resource identifier) to identify the particular resource involved in a interaction between components, as you saw on the previous example where a order is identified by /order/{orderId}. 

Representations

REST components perform actions on a resource by using a representation to capture the current or intended state of that resource. Representations consists of data or metadata describing the data. The response should include both, representation metadata and resource metadata. This data format of a representation is known as media type. A resource can be provided in multiple media types and you can choose the one that best fits the application.

You could ask the server to give you a "order" with the media type application/json, for example, because your client is mobile so you need less data. Or maybe you have an external client that needs to read another format like XML, then he just have to ask the server for an application/xml and it will give you the data you want.

Stateless

This is an important principle of REST which requires that every interaction between components must be stateless. It means that every response must have all the information for that request to be fully understood. The right way of controlling state in REST is using HATEOAS. 

Hypermedia as the engine of application state (HATEOAS)

REST concentrates all the control state into the representations received in response to interactions. The goal is to improve server scalability by eliminating any need for the server to maintain an awareness of the client state beyond the current request. On the example below you can see that the order already gives you the link within payment for the next transaction step maintaining the transaction control on the client-side.

Self-descriptive messages

Another constraint of REST is that messages should be self-descriptive and with all information needed for the task to be completed.

Well, that’s it. Now you have a guidance in how REST works. We’ll continue to talk about it in further articles.

See you later!

Source:

Roy Thomas Fielding dissertation, 2000.
REST in Practice book, 2010.