The majority of development work involved in creating a JavaScript single page application is generally going to be on the frontend, but not to be overlooked is the all-important data-transfer layer of your application, which communicates with the server and the database. Representational State Transfer (REST) is the standard architectural style of data transfer between client and server for the World Wide Web and the Internet of Things (IoT). Any time you use a web application, chances are that REST is being used to communicate data and transitions of state from the UI.
The beauty of using the REST architectural style for a SPA is that the frontend of your application can be entirely agnostic of what type of software is being used to retrieve requests on your server, as long as your application can be used over Hypertext Transfer Protocol (HTTP), the standard application protocol for the World Wide Web.
In this chapter, you will learn:
- The fundamental aspects of the REST architectural style
- How to write basic REST API endpoints for performing CRUD operations in a single page web application
- How to work with REST requests on your application frontend using AJAX
- The basics of some alternatives to REST, such as SOAP, WebSockets, MQTT, CoAP, and DDP
REST is the architectural style used to serve web pages and make requests on the World Wide Web, or simply the Web. Although the Internet and the Web are often referred to interchangeably, they differ in the fact that the Web is merely a part of the Internet.
The Web is a collection of documents, or web pages, which are served or hosted on computers all over the world and are connected via hyperlinks, or what are commonly referred to as links. These links are served over HTTP, the language of communication for the Web. REST is often confused with HTTP because of its mutual relationship with the Web, but HTTP and REST are far from the same thing.
REST is an architectural style, while HTTP is an application layer protocol. This means that while HTTP is the language of communication on the Web, REST is simply a set of rules for performing requests and operations on the Web. These operations performed through a REST architectural style are commonly referred to as Web Services. In this way, HTTP is simply the method of transport for the Web Services performed by an application using REST.
An architectural style, or architectural pattern, is a set of rules which provides developers with the ability to build abstraction layers as frameworks that are built to achieve a common language of interaction that is to ultimately be consumed by some type of client, or user agent. In the case of the Web, that user agent is a web browser.
A web abstraction layer, or web framework, can be written in any number of languages to provide Web Services via REST, or RESTful services, as long as that language can be hosted on a web server. When that framework follows the REST architectural style, the UI for any application using it can be completely agnostic, or unbiased, as to the technology behind the RESTful service.
A protocol, as it relates to the Web, is part of an abstraction layer of the Internet Protocol Suite, or TCP/IP, providing a common method of communication between connected computers.
The term TCP/IP is a combination of the Internet Protocol Suite's most widely used protocols: Transmission Control Protocol (TCP) and Internet Protocol (IP).
TCP
TCP is a transport layer protocol, which lies underneath the application layer. This means that services and information are transported up to the top-level application layer of the Internet Protocol Suite.
IP
IP is also a transport layer protocol. You have most likely seen this protocol associated with the term IP address, or Internet Protocol address, which is a unique numerical identifier for a device on a network. On the Web, domain names are commonly used to point to an IP address to make it easier for people to remember how to reach that address.
The application layer of TCP/IP is the abstraction layer that defines methods of communication between host computers that are connected through the Web. This layer specifies several protocols, with some of the most common being HTTP, FTP, SSH, and SMTP.
HTTP
HTTP is the primary protocol for data exchange within the application layer of TCP/IP, and it provides the foundation of communication for RESTful web services. HTTP is also responsible for serving a web page for display within a browser, and for sending data from a form on a web page to a server.
FTP
The File Transfer Protocol (FTP), is another standard protocol within the TCP/IP application layer that is used for transferring files between computers. FTP communication requires an FTP server and an FTP client.
SSH
Secure Shell (SSH) is another common protocol in the application layer which is used to allow secure remote logins to a non-secure network entry point. For SSH connections to work, a SSH server must be available to receive requests from a SSH client. A SSH client most often comes in the form of a terminal application with a command line interface (CLI).
SMTP
Simple Mail Transfer Protocol (SMTP) is the standard method of sending e-mail, or electronic mail, in the application layer of TCP/IP. SMTP may also be used to receive e-mail and is typically used for this purpose by e-mail servers. SMTP is not typically used by user-level e-mail clients for receiving e-mail, however. Instead, these clients more commonly use POP3 or IMAP.
POP3 is the third version of the Post Office Protocol, which is a standard application layer protocol for receiving e-mail over TCP/IP connections. POP3 is generally used to download e-mail to a local computer and then delete it from the host server.
IMAP is the Internet Message Access Protocol. It is also a standard application layer protocol for receiving e-mail over TCP/IP connections. IMAP is generally used as way to manage a host server e-mail inbox by multiple clients, and therefore it does not delete the e-mail from the server after downloading it to a local computer like POP3. The latest versions of IMAP also support tracking the state of an e-mail on the host server, such as read, replied to, or deleted.
REST defines a set of rules by which to make HTTP requests for a web application or service. HTTP requests can be made in any number of ways, but they are only RESTful if they follow that set of rules. HTTP provides the transport layer upon which those requests are made.
In the same way that a web application interacting with a REST API is agnostic of the type of software framework being used to serve the API endpoints, HTTP is agnostic of the types of operating systems being used across all of the servers which it communicates with.
The REST architectural style is governed by a set of constraints, or rules, that dictate how it should be implemented, interacted with, and handle data. REST was first defined by the American computer scientist Roy Fielding in a doctoral dissertation in 2000, along with these constraints.
REST is considered to be a hybrid architectural style in that it borrows from other architectural styles that existed before its conception. These other architectural styles lend greatly to the REST constraints outlined here.
The first constraint of REST is the client-server architectural style. This constraint exists to enforce the agnostic nature of REST, or the separation of concerns that is so fundamental to it:
This diagram shows the client-server relationship, and how they are separated. The client, or web browser, needs only display the UI for an application. The UI can be as simple or as sophisticated as deemed necessary, without affecting the REST architecture on the server. This REST constraint provides for scalability.
The second constraint of REST builds upon the client-server constraint in that the communication between client and server must be stateless. This means that any request from a web browser to the REST server must supply all expected information needed for the context of the request and the current session in order to expect the appropriate response from the server.
The server will have no stored information to help delineate the request, thereby making the REST server stateless and putting the burden of session state on the web browser:
This diagram depicts the client-stateless-server architectural style in which the web browser state can change and the REST server remains consistent. This REST constraint provides for visibility, reliability, and scalability, which are a few of the key benefits of using REST.
The third constraint of REST builds again upon the client-server and stateless constraints. A cache, or data stored for reuse, can be permitted for use by the browser for any given request based on the cacheability of that request as delegated by the REST server. If the server's cache component indicates that a request is cacheable, then the browser can cache it for future requests. Cacheability is often indicated in the case where a request made multiple times to a particular REST endpoint will likely result in an identical response each time:
This diagram depicts the client-cache-stateless-server architectural style. This style is just like client-stateless-server, but with the added component of a client cache.
The fourth constraint of REST is the use of a uniform interface among components of the system. This refers to the simplistic nature of the architecture involved in a REST implementation in which the components are decoupled. This allows each component of the architecture to evolve on its own, without affecting the others:
This diagram shows the uniform-client-cache-stateless-server architectural style. This combines the three previous architectural style constraints with the added constraint of uniform interface.
The uniform interface constraint is further subdivided into four of its own constraints.
A resource in REST is any conceptual mapping of information to a uniquely identifiable object. This object can be a person, place, or thing. An example of this in the case of the Web is a Uniform Resource Identifier (URI). More specifically, a Uniform Resource Locator (URL) is a special type of URI that provides a method to find a web resource and specifies how to obtain a representation of information from that resource. A URL is also commonly referred to as a web address. In relation to REST, a URL may also be referred to as an endpoint.
A representation in REST is a set of data which represents the current state of a resource. In a web architecture using REST, a JSON document can be used as a representation to pass between client and server, and manipulate or change a resource.
Messages in REST are the communication between components. In keeping with the constraint for a REST server to be stateless, the messages must be self-descriptive, meaning it carries all the information necessary to tell each component how it should be processed.
The fifth constraint of REST is a layered system, which is a hierarchy of architectural components, where each layer provides services to the layer above it and uses the services from the layer below it. In this manner, each layer only has visibility into one layer below it, thus making it agnostic of any layers down.
This concept is applied to distributed servers on the Web that are used to enhance the scalability of an application. For example, a web browser may communicate with any number of intermediate servers based on its location, but it is never aware of whether it is connected to the end server or one of those intermediate servers.
A layered system is also used to implement load balancing across servers. This allows additional servers to take on requests when the primary server is inundated with too many requests:
This diagram depicts a uniform-layered-client-cache-stateless-server. This architectural style combines the previous four with the added constraint of a layered system.
The sixth and final constraint of REST is the code-on-demand architectural style, and it is the only optional constraint. In this style, the server provides a set of executable code encapsulated in some form that is consumable by the browser. Some examples of this are Java applets, Flash animations running ActionScript, and client-side widgets running JavaScript.
Using code-on-demand can improve the flexibility of a REST application, but it also reduces visibility by encapsulating some functionality. This is why code-on-demand is an optional constraint for REST:
This diagram depicts the final REST architectural style. This combines all previously described constraints, which are required for REST, with the optional constraint of code-on-demand.