Definition

REST (REpresentational State Transfer)

REST (REpresentational State Transfer) is an architectural style for developing web services. REST is popular due to its simplicity and the fact that it builds upon existing systems and features of the internet's Hypertext Transfer Protocol (HTTP) in order to achieve its objectives, as opposed to creating new standards, frameworks and technologies.

Advantages and disadvantages of REST

There are several advantages to using REST. They are as follows:

  • Resource-based. A primary benefit of using REST, from both a client and server perspective, is that REST interactions are based on constructs which are familiar to anyone accustomed to using HTTP. Employing a resource-based approach, REST defines how developers interact with web services.
  • Communication. REST-based interactions communicate their status through numerical HTTP status codes. REST APIs use these HTTP status codes to detect errors and ease the API monitoring process. They include the following:
  • 404 error indicates that a requested resource wasn't found;
  • 401 status response code is triggered by an unauthorized request;
  • 200 status response code indicates that a request was successful; and
  • 500 error signals an unrecoverable application fault on the server.
  • Familiarity. Most developers are already familiar with key elements of the REST architecture, such as Secure Sockets Layer (SSL) encryption and Transport Layer Security (TLS).
  • Language-independent. When creating RESTful APIs or web services, developers can employ any language that uses HTTP to make web-based requests. This capability makes it easy for programmers to choose the technologies they prefer to work with and that best suit their needs.
  • Pervasive. The popularity of REST is due to its widespread use in both server- and client-side implementations. For example, on the server side, developers can employ REST-based frameworks, including Restlet and Apache CXF. On the client side, developers can employ a variety of frameworks (i.e., jQuery, Node.js, Angular, EmberJS, etc.) and invoke RESTful web services using standard libraries built into their APIs.
  • Web APIs. When it comes to caching, RESTful services employ effective HTTP mechanisms. For example, by providing many endpoints, a REST API makes it easier for developers to create complex queries that can meet specific deployment needs.

Disadvantages of REST are as follows:

  • Architecture. Developers working with REST frequently encounter limitations due to its architecture design. These include multiplexing multiple requests over a single TCP connection, having different resource requests for each resource file, server request uploads, and long HTTP request headers, which cause delays in webpage loading.
  • Stateless applications. Since HTTP does not store state-based information between request-response cycles, the client must perform state management tasks. This makes it difficult for programmers to implement server updates without the use of client-side polling or other types of webhooks that send data and executable commands from one app to another.
  • Definition. Developers generally disagree over defining REST-based designs. As an architectural style, REST lacks a clear reference implementation or a definitive standard that designates whether a specific design can be defined as RESTful. This also leads to uncertainty over whether a given web API conforms to REST-based principles.
  • Data overfetching/underfetching. RESTful services frequently return large amounts of unusable data combined with relevant information, typically the result of multiple server queries. These inefficiencies also increase the time it takes for a client to return all the required data.

Alternatives to REST

Alternate technologies for creating SOA-based systems or creating APIs for invoking remote microservices include XML over HTTP (XML-RPC), CORBA, RMI over IIOP and the Simple Object Access Protocol (SOAP).

In general, every technology has benefits and drawbacks. However, a unique feature of REST is that instead of requiring that developers work with custom protocols for client-server message exchanges, REST insists that the best way to implement network-based web services is to use the basic construct of the network protocol itself, which in terms of the internet is HTTP.

This is an important component, as REST is not intended to apply just to the internet; rather, its principles are intended to apply to all protocols, including WebDav and FTP.

REST vs. SOAP

The two competing styles for implementing web services are REST and SOAP. The fundamental difference between the two is the philosophical approach the two have to remote invocations.

REST takes a resource-based approach to web-based interactions. With REST, you locate a resource on the server, and you choose to either update that resource, delete it or get some information about it.

With SOAP, the client doesn't choose to interact directly with a resource, but instead calls a service, and that service mediates access to the various objects and resources behind the scenes.

SOAP has also built a large number of frameworks and APIs on top of HTTP, including the Web Services Description Language (WSDL), which defines the structure of data that gets passed back and forth between the client and the server.

Some problem domains are served well by the ability to stringently define the message format or can benefit from using various SOAP-related APIs, such as WS-Eventing, WS-Notification and WS-Security. There are times when HTTP cannot provide the level of functionality an application might require, and in these cases, using SOAP is preferable.

REST development

REST URIs and URLs

Most programmers are familiar with the way URLs and URIs work on the web. A RESTful approach to developing applications asserts that requesting information about a resource state should be as simple as invoking its URL.

For example, if a client wanted to invoke a web service that listed all the quizzes available here at TechTarget, the URL to the web service would look something like this:

www.techtarget.com/restfulapi/quizzes

When invoked, the web service might respond with the following JSON string listing all the available quizzes, one of which is about DevOps:

{ "quizzes" : [ "Java", "DevOps", "IoT"] }

To get the DevOps quiz, the web service might be called using the following URL:

www.techtarget.com/restfulapi/quizzes/DevOps

Invoking this URL would return a JSON string listing all the questions in the DevOps quiz. To get an individual question from the quiz, the number of the question would be added to the URL. So, to get the third question in the DevOps quiz, the following RESTful URL would be used:

www.techtarget.com/restfulapi/quizzes/DevOps/3

Invoking that URL might return a JSON string such as the following:

{ "Question" : {"query":"What is your DevOps role?", "optionA":"Dev", "optionB":"Ops"} }

As you can see, the REST URLs in this example are structured in a logical and meaningful way that identifies the exact resource being requested.

JSON and XML REST data formats

The example above employed JSON as the data exchange format for the RESTful interaction. The two most common data exchange formats are JSON and XML, and many RESTful web services can use both formats interchangeably, as long as the client can request the interaction to happen in either format.

Note that while JSON and XML are popular data exchange formats, REST itself does not put any restrictions on what the format should be. In fact, some RESTful web services exchange binary data for the sake of efficiency. This is another benefit to working with REST-based web services, as the software architect is given a great deal of freedom in terms of how best to implement a service.

REST and the HTTP methods

The example above only dealt with accessing data.

The default operation of HTTP is GET, which is intended to be used when retrieving data from the server. However, HTTP defines several other methods, including PUT, POST and DELETE.

The REST philosophy asserts that to delete something on the server, you would simply use the URL for the resource and specify the DELETE method of HTTP. For saving data to the server, a URL and the PUT method would be used. For operations that are more involved than simply saving, reading or deleting information, the POST method of HTTP can be used.

Developing REST APIs in Java

To accommodate the growing popularity of REST-based systems, there are several frameworks to help developers create RESTful web services.

Some of the more popular open source frameworks for creating Java-based, RESTful web services include Apache CXF, Jersey, Restlet, Apache Wink, Spring Data and JBoss' RESTEasy.

The general approach of each of these frameworks is to help developers build RESTful web services using semantics that are familiar to Java developers, including Java Platform (Enterprise Edition), the Servlet API and annotations, while at the same time offering built-in classes and methods that make it easier to conform to the basic tenets of REST.

REST and the IoT

Given the near ubiquity of REST APIs and the explosive number of devices on the internet of things (IoT), it seems to be a perfect pairing. Compact formats based on JSON, EXI and CBOR (Concise Binary Object Representation), a JSON offshoot, are used and RESTful APIs are likewise compact.

In an IoT scheme, devices work in a client-server relationship. In that relationship, devices can act as clients, servers or both. Devices can act as a client and initiate contact with a directory, such as the CoRE Resource Directory, or another device. Devices can also act in the capacity of an origin server or resource, such as to serve as a sensor, serving temperatures or other status indicators.

Yet, as noted above, all client-server operations using REST should be stateless, and any state management that is required should happen on the client, not the server. That means all messages must contain all the information to process it, independent from previous messages.

Two things have helped REST become popular with IoT developers. First, REST is already pervasive, well-understood and replicable. Second, because the data requested from resources in IoT tends to be simple, such as a sensor's current reading, and static, such as a manufacturer's device description, REST, which utilizes the internet's HTTP, is a natural fit.

History of REST

REST was first coined by computer scientist Roy Fielding in his year 2000 Ph.D. dissertation at the University of California, Irvine, titled "Architectural Styles and the Design of Network-based Software Architectures."

Chapter 5 of the dissertation, "Representational State Transfer (REST)," described Fielding's beliefs about how best to architect distributed hypermedia systems. Fielding noted a number of boundary conditions that describe how REST-based systems should behave. These conditions are referred to as REST constraints, with four of the key constraints described below:

  • Use of a uniform interface (UI). As stated earlier, resources in REST-based systems should be uniquely identifiable through a single URL, and only by using the underlying methods of the network protocol, such as DELETE, PUT and POST with HTTP, should it be possible to manipulate a resource.
  • Client-server-based. Within REST-based systems, there should be a clear delineation between the client and the server. For example, UI and request-generating concerns are the domain of the client. Meanwhile, data access, workload management and security are the domain of the server. This separation allows loose coupling between the client and the server, and each can be developed and enhanced independent of the other.
  • Stateless operations. All client-server operations should be stateless, and any state management that is required should happen on the client, not the server.
  • RESTful resource caching. The ability to cache resources between client invocations is a priority in order to reduce latency and improve performance. As a result, all resources should allow caching unless an explicit indication is made that it is not possible.
This was last updated in January 2021

Continue Reading About REST (REpresentational State Transfer)

Dig Deeper on API design and management

Software Quality
Cloud Computing
TheServerSide.com
Close