REST Architectural Constraints

What is REST? No, not the kind of rest you feel when you relax as you code from a hammock in the Bahamas. I’m referring to an architectural style that was first introduced over 20 years ago. If you knew that already, can you recall the last time you used a RESTful API? Whether you are new to programming or would like a quick refresher, this article will review what REST is before diving into the 6 guiding principles.

REST Overview

What is REST?

REST stands for REpresentational State Transfer and is an architectural style that was first presented by Roy Fielding in 2000. REST provides standards between computer systems on the web, making it easier for systems to communicate with each other.

RESTful API

REST determines how the API (application programming interface) looks like with a set of rules that developers must follow when they create their API. You should be able to get data (resource) when you link to the associated URL. In other words, each URL is called a request and the data you receive is the response. For instance, a resource from Facebook’s API could be a photo or user, each with a unique identifier. Essentially, when a RESTful API is called, the server will transfer to the client a representation of the state of the requested resource. Here are some REST API rules that should be kept in mind when creating API endpoints:

• REST API URIs should always end in a noun
• Use plurals to keep an API URI consistent throughout the application
• HTTP verbs are used to identify the action

Guiding Principles of REST

Now that we have some background on what REST is, let’s explore the architectural constraints that make any web service a true RESTful API…

Client -Server Communication

The client is the person or software who uses the API. The typical flow of information is fundamentally a request/response paradigm in which the client requests something and the server responds with the requested data. By separating the user interface concerns from the data storage concerns we improve the portability of the user interface across multiple platforms and improve scalability by simplifying the server components. This separation of concerns is the main principle of this constraint which allows the components to evolve independently, supporting the internet-scale requirement of multiple organizational domains.

Statelessness

All RESTFUL APIs are stateless. This means that the API holds no client context on the server beyond that relevant to the immediate request and the information needed to authenticate the client. Although the state can be stored in a database, it is not technically stored in the API itself. This implies that the communication must be stateless in nature and that the session state is kept entirely on the client. This improves visibility because a monitoring system does not have to look beyond a single request to determine the full nature of the request. The task of recovering partial failures enhances reliability while not having to store state requests improves scalability. However, there are some disadvantages to this simplicity. Since there is no stored state between requests, there is a risk of decreasing network performance with the increase of repetitive data requests.

Cache

REST APIs are cacheable because they can store data that has been previously requested and use that data upon demand. The Cache constraints do require that data within a response to a request must be labeled (either implicitly or explicitly) as either cacheable or non-cacheable. The client cache is only given the right to reuse that response if it is cacheable. Although this improves performance by reducing a series of interactions, there is a possibility that cache may not be as reliable if it differs from the data that would have been obtained if the request had been sent to the server directly.

Uniform Interface

This constraint emphasizes a uniform interface between components, which simplifies and improves the visibility of the interactions. Although this implementation encourages independent evolvability, the uniform interface could also degrade efficiency since information is transferred in a standardized form rather than one which is specific to an application’s needs. It is important to note the following architectural constraints required to obtain a uniform interface to help guide the behavior of the components: identification of resources; manipulation of resources through representations; self-descriptive messages; and, hypermedia as the engine of the application state.

Layered System

This alters an architecture constraint’s component behavior by restricting each component’s knowledge beyond the immediate layer with which they are interacting, thus creating an architecture composed of hierarchical layers. This confinement of a single layer system helps with overall system complexity and promotes independence among the components. Although this can be used to protect new services from legacy clients and simplify components by moving infrequently used functionality to a shared intermediary, there is a downside. The disadvantage is that they add overhead to the processing of data, which could reduce performance.

Code on Command

The final addition to our constraint set for REST comes from the code-on-demand style, which allows client functionality to be extended by downloading and executing code in the form of scripts. The reduction of the number of features required to be implemented and the flexibility of allowing features to be downloaded after deployment simplifies client functionality and improves system extensibility. Despite these improvements, there is a risk of reducing visibility, which is why this is an optional constraint within REST. By having an optional constraint, we have the ability to design an architecture that supports the desired behavior in the general case, but with the understanding that it may be disabled within some contexts.

Conclusion

We’ve learned that REST by design is stateless, highly scalable and flexible in output. Since REST is designed around the request-response model, it is considered the most useful environment when the client requests a wide range of calls where the server can respond with varied data. In conclusion, we can say that if an API is following these 6 guiding principles of REST, then it’s a RESTful API.

Additional Resources:

• Previous Blog: CRUD Operations Explained
• REST API Tutorial
• What is REST?
• REST Architectural Elements
• HTTP Request