What is a REST API? And what are its design constraints?

Anna Kelley

Your organization is in the API game, utilizing API connections to integrate and automate its services and processes. But are you maximizing the potential of those integrations?

If you’re on the varsity squad, you might be used to the traditional SOAP (simple object access protocol) API playbook. It’s time to consider how REST APIs—which offer standardized, scalable, and high-performance integrations—can optimize your team’s performance.

There are instances in which a faster, more agile, and more lightweight group of players is who you need on the court to make the right play. These are your REST APIs.

In this article, you’ll learn what a REST API is, how it compares to a SOAP API, and its six architectural constraints. We’ll also cover a case in which REST is used, and its benefits and drawbacks.

What is a REST API?

To understand what a REST API is (also known as a RESTful API), let’s put the term into a slightly larger context and provide its origins.

First, an API (application programming interface) is a channel that provides access to web services. This channel facilitates communication between systems.

The term REST (representational state transfer) was coined by computer scientist Roy Fielding, who examined how the constraints applied in the design of network-based software architectures would impact the performance and use of an architecture.

So, when we combine “REST” and “API,” we have a communication channel with a specific design. This design affects how information is sent and received.

The next logical question to ask is: what is the design of the REST API, and we’ll get to that in a minute when we cover Fielding’s 6 constraints. But first, let’s compare REST with its closest rival, SOAP.

Related: A guide to API development

Comparison to SOAP

The other most commonly used API is SOAP (simple object access protocol), which is a protocol that provides access to web services. REST isn’t a protocol; rather, it refers to the architectural style that is used to access web services. SOAP and REST each basically perform the same functions, but they’re suited to different situations. For example, SOAP provides better security for APIs used in financial transactions, while REST provides the scalability ideal for mobile app development.

Let’s clarify the difference between a protocol and an architecture, as it will help us understand how REST APIs work. We’ll use the example of Roy Fielding, the father of REST APIs, writing his dissertation on the subject.

Imagine Dr. Fielding, studying at the University of California Irvine, and about to embark on his dissertation research. The protocol of Fielding’s assignment was the system of rules applied to anyone writing such a paper: it had to be of a certain length, be formatted in a specific manner, and had to include cited research. Similarly, the protocols of a SOAP API are the predetermined compliance standards in the use of XML messaging.

The architectural style of the citation protocol is analogous to the citation model Fielding chose in formatting his paper: in this case, IEEE (Institute of Electrical and Electronics Engineers) style. He chose this style based on his discipline—computer science—knowing that the formatting of notations according to the discipline’s citation style would be recognizable to his readers. However, he could have chosen an alternate style, such as APA or MLA.

This is similar to how a REST API functions: using constraints particular to the REST “style,” it dictates what information is delivered and what it looks like.

Counterintuitive though it may be, the constraints of the style help make REST the most widely used type of API. The following example shows why these APIs are so common.

Example of a REST API

When the weather warms up and spring showers cease, outdoor enthusiasts look to make their reservations at their favorite campgrounds. To do so, they probably use the RESTful APIs on the campground’s web application.

From the website, a camper (the client) will access the campground map. The camper can choose to display only the sites available over Memorial Day weekend, which is done via a REST API. The API returns information (a resource) in the form of only the available sites for that weekend. This site availability over the holiday was retrieved from the website’s stored collection (the server) of site availability for the entire summer.

Just as customers will use RESTful APIs to make requests of the website, the campground employee will use these APIs in providing responses or modifying information as needed. For example, when campsite #13 is washed out by heavy rains, the employee must change its status to ‘unavailable’ in the system. This will display to potential campers, saving anyone from booking a soggy site.

Part of what makes these particular information exchanges RESTful is that after a request for a resource is made by a client, the server transfers back the current state of the resource in a standard representation.

The 6 architectural constraints of a REST API

In order to be considered RESTful, an API must adhere to these six design constraints. It’s important to consider this architecture when determining which type of API is best suited to the organization’s needs.

1. Client-server architecture

This constraint dictates that a client and a server need to be independent of one another so that either can be modified without impacting the other. This allows for a developer to make changes to a mobile app, for example, without altering the server, and vice versa. As a result, the RESTful API allows services to evolve independently, and this separation allows for each application to scale and, ultimately, facilitates growth and expansion.

2. Stateless

All REST APIs must exist as singular and self-contained representations of information, unconnected to and not reliant upon information on the server to complete themselves. Under a stateless constraint, there is no need for the application to be returned to over and over, which would require stable and ongoing data storage (stateful). Statelessness makes the API more reliable because fewer interactions with the server results in less room for error.

3. Cacheable

The ability to store and re-use data, within a certain amount of time, is valuable in an API integration because it reduces the number of requests made to the server. Thus, RESTful APIs are designed with this constraint to alleviate the overhead caused by increased requests and to streamline interactions between the client and server.

4. Uniform interface

A RESTful API requires a standardized interface that allows clients and servers to communicate in a single language such as HTTP, CRUD, and JSON. This uniform interface requires that requests made to the server define individual resources (any piece of information the API can provide the client), and provides the client the ability to act (deleting or modifying) the resource on the server. The action performed is made possible because each request must include the instructions for processing it.

5. Layered system

REST APIs require a system composed of multiple layers, each performing a specific function that contributes to the whole. These layers are organized into related groups and communicate according to a hierarchy of roles or actions. For example, in a system, layer A communicates to layer B, layer B to layer C, and so on. The entire communication chain ultimately produces an outcome or action.

6. Code on demand (optional)

Code on demand is the only optional constraint. It is the ability to transmit code from server to client, thereby altering the application’s code structure and extending the functionality of the client.

Pros and cons of using a REST API

There is a reason why the web is filled with RESTful APIs…actually, there are many!

First, APIs built within the REST constraints have remarkable flexibility due to their modular makeup of independent data and the decoupling of client from server. In addition, the API’s ability to handle multiple types of calls, and to return calls through a variety of formats (for example: XML, JSON, and YAML), make it versatile and an agile architecture to apply in systems that house or handle many API integrations. One last feature of their flexibility is the ease of making modifications to the API.

REST APIs require less bandwidth to operate, as they cache data and perform independently from servers. Therefore, they are high-performing without having to deplete resources. This translates into speed and efficiency across an organization’s systems and processes.

Finally, the architectural style is simple and standardized, meaning that just about anyone on the development side can understand it, and it is used and recognized across industry.

These benefits are what make RESTful APIs especially well suited to cloud technology and mobile applications.

However, while the uniformity of the style is easy to understand, it is not always easy to create for beginners given the challenge of building for the constraints. Even more seasoned developers can get frustrated with the REST API’s tendency to lose “statefulness,” which requires troubleshooting. These are important points to consider when assessing your API goals.

Ready to leverage REST APIs?

Workato, the leader in integration-led automation, offers a robust ecosystem of app connectors that use RESTful APIs.

Using these connectors, you can integrate your apps and then build workflow automations in Workato that work across them—all without writing a single line of code.

To learn more about Workato’s library of connectors and the workflow automations our platform lets you build, you can request a demo with one of our automation experts!

Request a demo