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. A major challenge to the distributed applications is attributed to the diversity of systems in an enterprise offering silos of business information, as depicted in the following diagram:
Often, an enterprise demands simplified access and updates to data residing in different systems. Fielding arrived at REST by evaluating all the 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 up with the following constraints that define a RESTful system:
- Client-server: This constraint keeps the client and 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 server to ease communication.
- Stateless: There should be no need for the service to keep user sessions. In other words, each request should be independent of the others. This improves scalability, as the server does not need to manage the state across multiple requests, with some trade-off on the network performance.
- 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 the interactions between the client and 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 the performance by providing shared caches at different levels. Being the door to the system, the top layer 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 at 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 the data is transferred between components and the benefits of the 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), to create RESTful architectures. Consequently, a RESTful architecture is one that is maintainable, extendable, and distributed.
Before all the 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 first need to qualify what it means for the web to be RESTful. On 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 connections, and unique hyperlinks to resources, where resources include all the documents available on every website, and the representation of these documents is 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, as servers require tracking 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.
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 that 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.
