dark mode light mode Search Menu


Brian Snelson on Flickr

While rest is something you do when you’re tired, throwing yourself into a comfy chair or crawling into your bed at night, REST means REpresentational State Transfer. It’s a way for software applications to work with each other, passing data and acting on data, with high performance and ease of maintenance.

For example, a website application could retrieve the last 20 customers who signed up in another website application.

Using REST, these applications can remember important details about how they work together and where they are in their process. How and where describe the state of the website applications, the State or S part of REST, while the T or Transfer part of REST describes the fact two or more applications can exchange or transfer data with each other using this method.

The RE for REpresentational is maybe the difficult part to explain about REST.

First, REST is a set of ideas about the ideal way to design software that talks to other software over the web using HTTP and URI protocols. If you don’t know, HTTP and URI are fancy words for the main way you use a web browser to call up web pages. Look near the top of your web browser and you’ll see http or https followed by the human readable address for a website page, for example, https://nytimes.com.

HTTP means HyperText Transfer Protocol while URI means Uniform Resource Identifier, for example, a URL you type into your web browser to call up a website. HTTP is an amazing invention because it allows a computer to talk with another computer anywhere in the world. Until the web and HTTP, computers did not have to talk with each other in a universal way and, as a result, only had more limited ways to interact.

The website in your browser uses the HTTP protocol to request web pages from the web server where the content is located online. HTTP retrieves both a resource (a web page) and a specific web page, both a concept and a representation of that concept.

Maybe the easy way to explain it is to think about an apple. You know the idea or concept of an apple — slightly round, often red, hand-sized, and grows on trees — but every apple is different, isn’t it? In the same way, REST uses HTTP to get a representation of a resource (a web page) and a specific example of the resource. That’s the REpresentational part of REST.

Programmers don’t design and code software to be 100% RESTful, the word used to describe software that meets at least the spirit and many of these design ideas. Instead, designing and building a RESTful application allows the programmer to make the most of web technologies, more than if everyone coded web applications from scratch.

Compared to other non web software applications, RESTful software is unusual because the web browser and web server connect without either knowing all the details about the other. The only constant between the browser and the server are the mediums of HTML, CSS, JavaScript, and a few others. For example, a web page form might include a Name field but the browser that displays the form has no idea, and doesn’t need to know, how the web server will handle data typed into the Name field on the form.

What are the key parts of REST?

Here are a few REST design principles programmers use:

Every bit of data has a unique identifier. A web page might display the pet names of cats, for example, so every pet name would have its own unique identifier. This makes it easy, for example, to use Fluffy’s unique identifier to tell the software application to change the name from Fluffy to Rocket.

Data resources use verbs — POST, GET, PUT, DELETE — to change properties of a data resource. Before REST, these verbs existed but were not well known or formally used.

The request for a data resource decides what form or representation the application should return the data in, for example, HTML, XML, or JSON. The form is not part of the data identifier. A web application, for example, might request details about Rocket the cat be returned in JSON format.

The request for a data resource also decides how the form or representation is used, discarded, or re-fetched.

These design principles give you a general idea how REST works for web applications.

Where does REST come from?

When we use something all the time, it’s easy to forget someone invented what we use. HTTP is no different. We use it all the time to view web pages in our web browsers but rarely stop to think about how HTTP, and REST, were created.

Like any invention, REST and HTTP exist to solve one or more problems. In 1995, Roy Fielding was a computer scientist and visiting scholar doing research at MIT with Tim Berners-Lee and the Worldwide Web Consortium, the group that defined standards for the web. Fielding spent time defining how these new technologies worked together. REST was how Fielding described the best way to use HTTP and URI technology which, in turn, existed to make it possible for web pages to find each other and interact.

Learn More



Roy Fielding


Architectural Styles and the Design of Network-based Software Architectures

Complete dissertation by Roy Fielding which includes Chapter 5 about REST.

What Exactly is RESTful Programming?


How I Explained REST to My Wife






What is the Difference between a URI, a URL, and a URN?