Overview of REST architectural style

Abstract

Mazalov R.A., Chernyshova A.V., Gilmanova R.R. Overview of REST architectural style. This paper reviews software system development paths, it provides the definition of terms: vertical scalability, horizontal scalability and middleware of distributed system. It presents different approaches to data exchange in distributed systems. The brief overview of REST web service architectural style is also done. In this overview architectural constrains that are applied on a system are listed. The article identifies pros of this architectural style and reasons of its popularity among developers.

Software system deployment ways. Distributed systems and their requirements

Nowadays all large software systems are distributed. In development process, a software system can increase in such volume that power and storage capacity of one server isn't enough. In this case, there are two ways to deploy the software system. The first way is to increase server performance by modifying its components or to move to a server with better processing power and storage capacity, which is called vertical scalability. The other way is to partition the system into smaller structural components and place them on separate servers, which is called horizontal scalability [1].

The first way is a dead end, since in practice over time it will not be possible to find an even more productive server than the previous one. Therefore, all software systems sooner or later choose the second deployment way. Systems such as the social network Facebook [2], the social network Twitter [3], the cloud service Google Drive [4] and the Internet are distributed.

All distributed systems must satisfy the following requirements: openness, scalability, stability, security [5]. To fulfill these requirements, distributed systems include an additional software layer, which is between the application and transport layers relative to the OSI model, called middleware [6]. Now let’s look at middleware in more detail.

Middleware. Different approaches to data exchange between components of a distributed system. REST as one of these approaches

Middleware should help developers create open, scalable, resilient, and secure distributed systems. Figure 1 shows an interaction model of computing systems and marks the middleware level in this model.

Figure 1 — Interaction model of computing systems

Middleware should in particular provide data exchange between components of a distributed system. Currently, there are two concepts of interaction between software components:

• message queues [7];
• remote procedure call (RPC) [8] or component’s object method call.

The interaction between remote components is based on the TCP/IP sockets [9], but they don’t determine format of a transmitted message. Based on the TCP, HTTP [10] protocols, higher level of abstraction messaging protocols can be built to implement message queues or remote procedure calls.

One of the ways to data exchange is the REST architectural style, which is used to create web services. REST is, in essence, an alternative to RPC. On the Internet, a remote procedure call can be represented as a normal HTTP request (GET or POST, such the request is called REST request), and necessary data is transmitted as query parameters. An example of the request is shown in Figure 2.

Figure 2 — Example of a REST request

In the example, a homes resource is requested, with a parameter passed through query parameters that limits an amount of resources in a response. The response of the request is a representation of the resource in JSON format.

REST is a consistent set of constraints to consider when designing distributed web services. Web services that conform to the REST architectural style, called RESTful Web services. RESTful Web services allow the requesting systems to access and manipulate textual representations of Web resources by using a uniform and predefined set of stateless operations. Other kinds of Web services, such as SOAP Web services, expose their own arbitrary sets of operations [11].

The term REST was coined by Roy Fielding [12], one of the creators of the HTTP protocol, in his 2000 PhD dissertation Architectural Styles and the Design of Network-based Software Architectures at UC Irvine. He developed the REST architectural style in parallel with HTTP 1.1 of 1996–1999, based on the existing design of HTTP 1.0 of 1996 [11].

Today REST has virtually displaced all other approaches, including design based on SOAP and WSDL. Thus, the study of this approach is relevant.

Architectural constraints of REST

REST puts a number of constraints on a system. If the system follows them, it can be considered RESTful. Let’s look at the constraints.

Client-Server. The system uses the client-server architecture. For example, such separation of interfaces means that clients can be not related to data storage, while data remains on a server. It improves mobility of a client code. Servers aren’t depended on a user interface or state, and servers become simpler and more scalable. Servers and clients can be replaced and developed independently while the interface is unchanged.

Stateless. A server should not store any client information. A request should store all the needed information for its processing and client identification if necessary.

Cache. Each response should be marked whether it will be cached or not, to prevent clients from reusing obsolete or incorrect data in responses to further requests.

Uniform Interface. Uniform interface defines the interface between clients and servers. This simplifies and separates an architecture, which allows each part to develop independently.

Let’s list four principles of the uniform interface:

• identification of resources. In REST, a resource is everything that can be given a name, for example, user, image, subject, etc. Each resource in REST must be identified by a stable identifier that does not change when a state of the resource changes. The identifier in REST is the URI [13].
• manipulation of resources through representations. A representation in REST is used to perform actions on resources. The resource representation is current or desired state of a resource. For example, if the resource is a user, then the representation may be an XML or HTML description of that user.
• self-descriptive messages. A request and response should contain all necessary information for their processing. There shouldn’t be additional messages or caches for processing a single request. In other words, there isn’t state saved between resource requests. This is very important for system scaling.
• HATEOAS (hypermedia as the engine of application state). A resource state is transmitted through a content of the body, query string parameters, request headers, and a requested URI (resource name). This is called hypermedia (or hyperlinks with hypertext). HATEOAS also means that, if necessary, the links can be contained in the response body (or headers) to support the URI, retrieve the object itself or requested objects.

Layered System. In REST, the system can be divided into a hierarchy of layers, but with the condition that each component can see components of only the next layer. For example, if a PayPal service is called, and it calls a Visa service, then a caller of the PayPal service shouldn’t know anything about calling of the Visa service. Use of intermediate servers can increase scalability due to load balancing [14] and distributed caching [15]. Intermediate nodes can also be subject to a security policy [16] in order to ensure confidentiality of information [17].

Code-On-Demand (optional). In REST, client-side loading and execution of program code is allowed. Roy Fielding claims that the optional constraint allows you to design an architecture that supports desired functionality, with the exception of some contexts.

With the constraints given above that are putted on the system during design, the system acquires a number of useful properties. Let’s review these properties.

Architectural properties of REST. Advantages of REST and reasons of its popularity

Let’s look at properties that a system acquires in case of putting REST architectural constraints on it:

• scalability of the interaction of system components;
• general availability and simplicity of interfaces;
• independent deployment of components, ease of modification;
• the intermediate components that reduce delay, enhance security;
• reliability (due to the lack of the need to save information about the client’s state, which may be lost).

As you can see from the list, these properties allow to follow all the requirements that distributed systems must satisfy.

Let us consider in more detail advantages that the REST architectural style provides for data exchange between components.

There is an absence of additional internal layers, which means that data transfers in same form as the data itself. Thus, data is not represented in XML [18], as SOAP and XML-RPC [19] do, AMF [20] is not used, as Flash [21] does, etc.

Each unit of information (resource) is uniquely determined by a URL [13] — this means that the URL is the primary key for the unit of data. Moreover, it doesn’t matter in what format the data is stored — it can be HTML [22], jpeg [23], or a Microsoft Word [24] document.

How resource information is managed is entirely based on a data transfer protocol. The most common protocol is HTTP. For HTTP, actions on data is performed using set of methods: GET (get), PUT (add, replace), POST (add, change, delete), DELETE (delete). Thus, the CRUD operations [25] (Create-Read-Update-Delete) can be done with all 4 methods, or only with the help of GET and POST.

Recently, REST has become a popular choice for developers to create public APIs [26] for web services. These public APIs also come with detailed documentation where you can get all the information you need to retrieve data through the API.

There are three main reasons why REST is so popular for web service development.

The first reason is that REST provides data in the form of resources (for example, user), and not in the form of services (for example, getUser), as in SOAP.

The other reason is that REST inherits HTTP operations, thus, you can make simple API calls using well-known HTTP methods like GET, POST, PUT and DELETE.

Another reason is that the REST architecture allows API providers to deliver data in various formats, such as plain text, HTML, XML, YAML and JSON [18], which is one of its most favorite features. Due to the growing popularity of REST, the easy and human-readable JSON format has also quickly gained popularity, as it’s great for quick and painless data exchange.

Conclusions

This study examines the approaches to deployment of distributed software systems, the concepts of vertical, horizontal scaling and middleware of distributed systems. The approaches to data exchange in distributed systems are explored. The review of REST architectural style is carried out. Advantages of REST are revealed. REST is not a protocol; its use makes development of distributed web services simple and flexible, which makes it popular among developers.

References

1. Масштабируемость // Википедия [Электронный ресурс]. — Режим доступа: https://ru.wikipedia.org/wiki/Масштабируемость
2. Facebook // Facebook [Electronic resource]. — Mode of access: https://facebook.com
3. Twitter // Twitter [Electronic resource]. — Mode of access: https://twitter.com
4. Google Drive // Google [Electronic resource]. — Mode of access: https://www.google.com/intl/ru_ALL/drive/
5. Щелоков С.А. Проектирование распределенных информационных систем [Текст] : курс лекций по дисциплине «Проектирование распределенных информационных систем» / С.А. Щелоков, Е.Н. Чернопрудова; Оренбургский гос. ун-т. — Оренбург : ОГУ, 2012. — 195 с. : ил.
6. Middleware // RedHat [Electronic resource]. — Mode of access: https://www.redhat.com/en/topics/middleware/what-is-middleware
7. Message queuing // CloudAMQP [Electronic resource]. — Mode of access: https://www.cloudamqp.com/blog/2014-12-03-what-is-message-queuing.html
8. What is Remote Procedure Call (RPC)? // Poftut [Electronic resource]. — Mode of access: https://www.poftut.com/what-is-remote-procedure-call-rpc/
9. W. Richard Stevens. TCP/IP Illustrated, Vol. 1: The Protocols [Text] : Addison-Wesley Professional Computing Series. — 1st ed. — Boston : Addison-Wesley Professional, 1994. — 600 pp. : illus.
10. Hyper Transfer Protocol (HTTP) // MDN [Electronic resource]. — Mode of access: https://developer.mozilla.org/en-US/docs/Web/HTTP
11. Representational state transfer // Wikipedia [Electronic resource]. — Mode of access: https://en.wikipedia.org/wiki/Representational_state_transfer
12. Roy T. Fieldling [Electronic resource]: Senior Principal Scientist. — Mode of access: https://roy.gbiv.com
13. What is the difference between a URI and a URL? // dev.to [Electronic resource]. — Mode of access: https://dev.to/flippedcoding/what-is-the-difference-between-a-uri-and-a-url-4455
14. Ali Alakeel. Load Balancing in Distributed Computer Systems [Text] / Ali Alakeel // International Journal of Computer Science and Information Security / University of Tabuk. — Tabuk, 2010. — p. 8-13
15. Our 5-minute guide to distributed caching // ITPRO [Electronic resource]. — Mode of access: https://www.itpro.co.uk/virtualisation/30271/our-5-minute-guide-to-distributed-caching
16. Key Elements of an Information Security Policy // Infosec [Electronic resource]. — Mode of access: https://resources.infosecinstitute.com/key-elements-information-security-policy
17. What is Confidential Information // EveryNDA [Electronic resource]. — Mode of access: https://www.everynda.com/blog/what-is-confidential-information
18. YAML vs JSON vs XML | What is the Difference Between Them? // CSEstack [Electronic resource]. — Mode of access: https://www.csestack.org/yaml-vs-json-vs-xml-difference
19. XML-RPC vs SOAP // weblog.masukomi.org [Electronic resource]. — Mode of access: https://weblog.masukomi.org/2006/11/21/xml-rpc-vs-soap
20. Action Message Format (AMF) // Wikipedia [Electronic resource]. — Mode of access: https://en.wikipedia.org/wiki/Action_Message_Format
21. Adobe Flash Player // Adobe [Electronic resource]. — Mode of access: https://www.adobe.com/ru/products/flashplayer.html
22. What is HTML? // W3C HTML [Electronic resource]. — Mode of access: https://www.w3.org/html/
23. The JPEG (Joint Photographic Experts Group) image file format // ntchosting [Electronic resource]. — Mode of access: https://www.ntchosting.com/encyclopedia/multimedia/jpg-image-file-format/
24. Microsoft Word // Microsoft [Electronic resource]. — Mode of access: https://products.office.com/en-us/word
25. What is CRUD? // Codeacademy [Electronic resource]. — Mode of access: https://www.codecademy.com/articles/what-is-crud
26. What exactly IS an API? // Medium [Electronic resource]. — Mode of access: https://medium.com/@perrysetgo/what-exactly-is-an-api-69f36968a41f