Overview

REST, an acronym for Representational State Transfer, is an architectural style for developing web services. Its popularity stems from its simplicity and its foundation on the existing systems and functionalities of the Internet's Hypertext Transfer Protocol (HTTP) to achieve its goals, rather than creating new standards, frameworks, and technologies. A distinctive feature of REST is that it does not require developers to use custom protocols for client-server message exchange. Instead, it asserts that the best way to implement network-based web services is to utilize the fundamental structure of the network protocol itself—in the case of the Internet, that is HTTP.

Advantages of Using REST

• A primary benefit of using REST from both client and server perspectives is that REST interactions are based on constructs familiar to anyone accustomed to using HTTP. REST adopts a resource-based approach, defining how developers interact with web services.
• REST-based interactions communicate their status through numeric HTTP status codes. REST APIs use these HTTP status codes to detect errors and simplify the API monitoring process.
• Most developers are already familiar with key elements of the REST architecture, such as security and encryption protocols like SSL and TLS.
• When creating RESTful APIs or web services, developers can use any language that utilizes HTTP to make web-based requests. This feature allows programmers to easily choose the technology they prefer and that best suits their needs.
• REST's popularity is due to its widespread use in both server-side and client-side implementations. For example, on the server side, developers can use REST-based frameworks including Restlet and Apache CXF. On the client side, developers can use various frameworks (e.g., jQuery, Node.js, Angular, EmberJS, etc.) and call RESTful web services using standard libraries built into their APIs.
• Regarding caching, RESTful services employ efficient HTTP mechanisms. For instance, by providing numerous endpoints, REST APIs enable developers to more easily create complex queries that meet specific deployment needs.

Development History

The Web began entering daily use around 1993-1994 when general-purpose websites became available. At that time, descriptions of the Web's architecture were fragmented, and the industry faced pressure to agree on standards for some Web interface protocols. For example, several experimental extensions were added to the communication protocol (HTTP) to support proxies, and more extensions were being proposed. However, a formal Web architecture was needed to assess the impact of these changes.

The W3C and IETF working groups jointly began creating formal descriptions of the Web's three main standards: URI, HTTP, and HTML. Roy Fielding participated in the creation of these standards (specifically HTTP 1.0 and 1.1, and URI). Over the next six years, he developed the REST architectural style, tested its constraints against Web protocol standards, and used it as a means to define architectural improvements—and identify architectural mismatches.

In 2000, Fielding defined REST in his doctoral dissertation, "Architectural Styles and the Design of Network-based Software Architectures," at the University of California, Irvine. It identified requirements applicable when creating globally distributed, network-based applications, such as the need for a low barrier to entry to achieve global adoption.

Protocol Standards

Architectural Concepts

The REST architectural style is designed for network-based applications, particularly client-server applications. More importantly, it is designed for Internet-scale use, so the coupling between the user agent (client) and the origin server must be as lightweight (loose) as possible to facilitate large-scale adoption. This is achieved by creating an abstraction layer on the server, defining resources that encapsulate entities (e.g., files) on the server, thereby hiding underlying implementation details (file servers, databases, etc.). But this definition is even more general: any information that can be named can be a resource: an image, a database query, a time service (e.g., "today's weather in London"), or even a collection of other resources. This approach allows for maximum interoperability between clients and servers in long-lived, Internet-scale environments that cross organizational (trust) boundaries.

Clients can only access resources using URIs. In other words, clients request resources using URIs, and servers respond with representations of the resources. The representation of a resource is another important concept in REST; to ensure the response can be interpreted by as many client applications as possible, the resource's representation is sent in a hypertext format. Resources are manipulated through hypertext representations transmitted in messages between client and server.

Architectural Properties

• Performance in component interactions, which can be a dominant factor in user-perceived performance and network efficiency;
• Scalability to support a large number of components and interactions between components;
• Simplicity of a uniform interface;
• Modifiability of components to meet changing needs (even while the application is running);
• Visibility of communication between components by service agents;
• Portability of components by moving program code and data;
• Reliability, the ability to resist failure at the system level in the presence of failures within components, connectors, or data.

Architectural Constraints

The REST architectural style defines six guiding constraints. When these constraints are applied to a system's architecture, it acquires desirable non-functional properties such as performance, scalability, simplicity, modifiability, visibility, portability, and reliability. Systems that conform to some or all of these constraints are loosely termed RESTful.

Client-Server Architecture

By separating user interface concerns from data storage concerns, the portability of the user interface is improved. This separation improves user interface portability across multiple platforms and, by simplifying server components, improves system scalability. Most crucially, separating these two concerns (user interface and data storage) makes it possible for different user terminals to enjoy the same data.

Statelessness

Each request from a client to a server must contain all the information necessary to understand the request. This constraint improves system visibility (statelessness means clients and servers do not need to store each other's details; the server only needs to process the current request without knowing the entire request history), reliability (statelessness reduces the server's task of recovering from partial failures), and scalability (statelessness allows the server to easily release resources because it doesn't need to maintain state across multiple requests). However, it can also lead to resource waste due to the lack of contextual support.

Uniform Interface

The uniform interface is the foundation of any RESTful system design. It simplifies and decouples the architecture, allowing each part to evolve independently. The four constraints of this uniform interface are:

• Resource identification in requests – identifying individual resources in requests, e.g., using URIs in RESTful web services.
• Resource manipulation through representations.
• Self-descriptive messages – each message contains enough information to describe how to process the message.
• Hypermedia as the Engine of Application State (HATEOAS) – after accessing the initial URI of a REST application (similar to a human web user accessing a website's homepage), a REST client should be able to dynamically use server-provided links to discover all available resources it needs.

Cacheability

Clients and intermediaries can cache responses. Responses must implicitly or explicitly define themselves as cacheable or non-cacheable to prevent clients from providing stale or inappropriate data in response to further requests. Well-managed caching can partially or completely eliminate some client-server interactions, thereby further improving scalability and performance. Caching can be performed in the client computer's memory or browser cache storage.

Layered System

A client cannot ordinarily tell whether it is connected directly to the end server or to an intermediary along the way. If a proxy or load balancer is placed between the client and server, it will not affect their communication, and no updates to client or server code are required. Intermediary servers can improve system scalability by enabling load balancing and providing shared caches.

Code on Demand (Optional)

REST allows client functionality to be extended. For example, by downloading and executing code in the form of applets or scripts. While this can improve system extensibility, it reduces visibility. Therefore, it is only an optional constraint of REST.

Operating on Resources

For operating on resources, corresponding HTTP verbs are used. Common verbs include the following five (with corresponding SQL commands in parentheses):

GET (SELECT): Retrieve a resource (one or more items) from the server.
POST (CREATE): Create a new resource on the server.
PUT (UPDATE): Update a resource on the server (client provides the complete resource after changes).
PATCH (UPDATE): Update a resource on the server (client provides the changed properties).
DELETE (DELETE): Delete a resource from the server.