REST is not an architecture; rather, it is a set of constraints that creates a software architectural style, which can be used for building distributed applications.
Tip
You can read Architectural Styles and the Design of Network-Based Software Architectures, Roy Fielding, 2000, which talks about the REST architectural style by visiting http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm.
Fielding arrived at REST by evaluating all networking resources and technologies available for creating distributed applications. He observed that without any constraints, one may end up developing applications with no rules or limits that are hard to maintain and extend. After considerable research on building a better architecture for a distributed application, he ended with the following constraints that define a RESTful system:
Client-server: This constraint keeps the client and the server loosely coupled. In this case, the client does not need to know the implementation details in the server and the server is not worried about how the data is used by the client. However, a common interface is maintained between the client and the server to ease the communication.
Stateless: There should be no need for the service to keep users' sessions. In other words, each request should be independent of the others.
Cacheable: This constraint has to support a caching system. The network infrastructure should support a cache at different levels. Caching can avoid repeated round trips between the client and the server for retrieving the same resource.
Uniform interface: This constraint indicates a generic interface to manage all interactions between the client and the server in a unified way, which simplifies and decouples the architecture. This constraint indicates that each resource exposed for use by the client must have a unique address and should be accessible through a generic interface. The client can act on the resources by using a generic set of methods.
Layered system: The server can have multiple layers for implementation. This layered architecture helps to improve scalability by enabling load balancing. It also improves performance by providing shared caches at different levels. The top layer, being the door to the system, can enforce security policies as well.
Code on demand: This constraint is optional. This constraint indicates that the functionality of the client applications can be extended at runtime by allowing a code download from the server and executing the code. Some examples are the applets and the JavaScript code that get transferred and executed on the client side at runtime.
The following diagram illustrates a high-level architectural view of a RESTful system:
The preceding constraints do not dictate what kind of technology to use; they only define how data is transferred between components and the benefits of following guidelines. Therefore, a RESTful system can be implemented in any available networking architecture. More importantly, there is no need for us to invent new technologies or networking protocols. We can very well use the existing networking infrastructures, such as the World Wide Web (WWW), or simply the Web, to create RESTful architectures. Consequently, a RESTful architecture is one that is maintainable, extendable, and distributed.
Before all REST constraints were formalized, we already had a working example of a RESTful system, the web. Now, you may ask why introduce these RESTful requirements to web application development when it is agreed that the Web is already RESTful.
Here is the answer: We need to first qualify what it means for the web to be RESTful. On the one hand, the static web is RESTful because static websites follow Fielding's definition of a RESTful architecture. For instance, the existing web infrastructure provides caching systems, stateless connection, and unique hyperlinks to resources, where resources are all of the documents available on every website and the representations of these documents are already set by files being browser readable (the HTML files, for example). Therefore, the static web is a system built in the REST-like architectural style. In simple words, we can say that REST leverages these amazing features of the web with some constraints.
On the other hand, traditional dynamic web applications have not always been RESTful because they typically break some of the outlined constraints. For instance, most dynamic applications are not stateless because servers track users through the container sessions or client-side cookie schemes. Therefore, we conclude that the dynamic web is not normally built in the REST-like architectural style.
Note
The REST architectural style is not specific to any protocol. However, as HTTP is the primary transfer protocol for the web today, REST over HTTP is the most common implementation. In this book, when we talk about REST, we refer to REST over HTTP unless otherwise stated.
Now, you may be curious to learn more about a RESTful system. The rest of the chapter will definitely help you to know the internals. However, the topics on the RESTful system, which we are going to discuss in the coming sections, may need some basic knowledge of HTTP. So, let's take a crash course on HTTP to learn some basics and then proceed with our discussions thereafter. You can skip the next section if you are already familiar with HTTP.